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