[systemd-devel] Creating a roaming USB home area using homectl

[Lennart Poettering]

On So, 08.03.20 22:07, Matthew Wardrop (mpwardrop at gmail.com) 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