Thanks for your response, Lennart!
I've created the requisite public keys to /var/lib/systemd/home; but things still aren't working. Based on issue https://github.com/systemd/systemd/issues/15178 am I correct in understanding that the key revocation warning also covers instances where the identity has not been locally created (or is empty)? Is there a way to "re-fixate" a home area (setting up group membership / etc) using homectl, or do you need to manually create the appropriate "*.identity" file?
Best,
M
On Tue, 31 Mar 2020 at 07:21, Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
On So, 08.03.20 22:07, Matthew Wardrop (mpwardrop@xxxxxxxxx) wrote:
> Greetings all,
>
> When I heard news of systemd-homed I was excited, since it was my
> understanding I'd be able to ferry only my external hard drive between home
> and work during my bicycle commute, and be able to forget about user id
> issues/etc. I tried to set it up, but must be missing something.
>
> On one machine I ran:
> $ sudo homectl create mawardrop --storage=luks -G docker -G wheel -G input
> --image-path=/dev/sdc --shell=/usr/bin/zsh
> (where /dev/sdc was my external hard drive).
>
> Everything works well locally. I can log in, and out, and the luks image
> successfully mounts and unmounts; but when I attempt to login in on a
> different machine also configured with systemd-homed, I come across two
> issues.
>
> 1) In order for `homectl list` to show my new home folder, I need to
> restart the homed service after plugging in the hard drive. That means I
> need to have it plugged in on machine boot, or log in as a different user
> and restart the service, for it to show up in in the login manager.
Hmm, this is a bug. This should just work... homed subscribes to udev
events to see everything plugged in. Can you file a bug about this.
> 2) Even once visible, it appears as "unfixated". Any operations on the home
> area such as `authenticate` or `activate` result in the error: "Operation
> on home mawardrop failed: Failed to execute operation: Key has been
> revoked".
homed doesn't allow just anyone to login. It signs user records with a
cryptographic key, and only allows users signed by a key known locally
to log in.
This needs better documentation, but the essence is that homed uses
a private key stored in /var/lib/systemd/home/local.private to sign
records with, and accepts all records signed by public keys matching
/var/lib/systemd/home/*.public. If you create a local user and
/var/lib/systemd/home/local.private does not exist yet a new key is
automatically generated and stored there, and its public key stored in
/var/lib/systemd/home/local.public.
This means, if you want users created on machine quux to be able to
log into machine waldo, make sure to copy quux's
/var/lib/systemd/home/local.public file to waldo, maybe into a file
/var/lib/systemd/home/quux.public.
> Am I just too early to the game, in that multi-machine setups are not yet
> supported? Or is there something obvious I am missing?
They are supported, just underdocumented ;-)
Lennart
--
Lennart Poettering, Berlin
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
