8️⃣ Here's the 8th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.
You might be aware of systemd-homed, a small service in systemd which can manage encrypted, portable home directories for you. It supports multiple storage backends, but the most relevant maintains a per-user LUKS disk image for each home directory, and ties the encryption of it to your user's authentication credentials. It supports FIDO2 and PKCS11 (in addition…
… to classic passwords and recovery keys) for unlocking the home directories.
Home directories maintained by systemd-homed come at a much higher security level than traditional home directories. Most importantly: you cryptographically unlock your home dir at the moment of login, and unless you logged in your home directory is entirely inaccessible because there's no decryption key available the system could decrypt it with.
…traditional UNIX systems allowed do not work on systemd-homed. For example, per-user cronjobs don't really work anymore as long as the user hasn't logged in, because they cannot access the user's home directory. More interestingly though SSH logins into locked home directories so far wasn't supported: ssh authentication works differently from traditional PAM based authentication after all: it entirely bypasses the Linux PAM auth stack (it does run the account and service stacks however)…
… and instead does authentication via asymmetric key pairs, i.e. those things you traditionally maintain in your .ssh/ directory in the home directory.
And that's a problem for systemd: if systemd-homed cannot hook into the authentication mechanism, ask the user for a LUKS passphrase, or ask them to touch the FIDO2 key or enter its PIN, then it cannot automatically unlock your home directory when you log in via SSH. (If you already logged in before locally, then SSH would work).
So, what's new regarding this problem in v256? Well, it works now: you finally can log in via SSH directly into your super secure systemd-homed account.
How did we make this happen? Roughly like this: first, we let SSH do its authentication. If that succeeded then we permit the log in to go though, but temporarily provide a slightly different user record for the user, where the login shell in the record is redirected to a small stub tool provided by systemd.
This stub tool has only one job: ask the user interactively for the unlock password/PIN/touch/… and then execve() the actual user's shell.
Or in other words: one ssh allows a login to go through you'll end up in something that behaves a lot like a shell, but ensures the home directory is unlocked first, before it passes control to the actual shell.
This little stub hence runs without any home dir accessible, but under the user's identity. It's job is to make the home dir accessible, and…
… then get out of the way, and let the real shell take over.
Howe does this feel from the client side? Basically if you "ssh" into a host like that, the regular SSH authentication takes place. If this succeeds there are now two options:
if the home dir alreads has been unlocked, you get the shell directly as on classic UNIX systems.
if the home dir as not been unlocked yet, you get a quick prompt to do so, and once that succeeded you get your shell.
@pid_eins can you disable this mechanizm when SSH public keys are stored outside of user home directories? This is typically the case on nixos where user keys get deployed to /etc
@enkiusz in a systemd-homed world the SSH public key is part of the user record btw, precisely to have it around without having to unlock the home dir.
The bigger problem with ssh logins really was the fact that to unlock the home dir we need the decryption key, and ssh doesn't really make it easy for us to ask for it, hence the little stub shell thing we came up with.
@pid_eins@enkiusz it may be neat to find out if the forwarded (if so) agent can be used instead of asking interactively, this way the scheme could work for sftp too. The idea would require some sort of software token on the client authorized to forward an unlocking key which could be stored in another LUKS key slot.
A scheme like the one used by clevis/tang would permit to have a credential stored securely on the client that can't be used to extract the key w/o the server involvement.
@simo5@enkiusz so the operation ssh-agent does for auth is signing a nonce, and thats it. We could shoehorn this into an unlock scheme for disk encryption, but i am not sure this is so great: i.e. take a random value at enrollment time, let ssh-agent sign it with its ssh priv key and then (mis-)use the resulting signature as symmetric disk encryption key. Under the assumption that only the owner of the privkey can generate valid sigs and that sigs have no other inputs this should be safe.
@simo5@enkiusz another idea would be to combine ssh-agent auth with a local tpm. I.e. encrypt the disk encryption key with some key stored in the tpm that it only reveals if a tpm generated nonce can be signed by the client.
This is similar to how chromeos does unlocking via fido2, where also the relevant key is released from the tpm to the os only if the fido2 key can answer a challenge from the tpm.
@pid_eins I’m struggling to find the earlier threads for previous days.
Can you pin a toot to your timeline with the first toot for each feature so we can find the earlier threads? You can also set reply visibility as “unlisted” so only the first toot for each thread shows up on your page, also making it much easier for readers to find each one.
Either way, thank you for your ongoing work on systemd!
@pid_eins Is there any chance of bypassing all this if the systemd-homed managed home directory isn't actually encrypted (i.e. using --storage=directory)?
I had looked at homed a while back as a possible replacement for a system where we wanted to manage users separate from the base operating system image. It was using full disk encryption, so separately encrypting the home directory was less important.
@jamesh For this my focus was on encrypted home dirs of course. I made sure the stub shell is skipped when the home dir is already unlocked. If this isn't skipped on --storage=directory currently then I would consider that a bug, but I must admit I didn't test that combination recently.
@Hikari@pid_eins sshd does use PAM for authentication. The problem is that if you bypass password auth, then the module that unlocks your home directory can't use that password to access the disk encryption key.
@jamesh@Hikari It uses PAM for the session setup and to see if the account is valid. It doesn't use it for authentication (unless you allow password auth, which you hopefully don't) though, and that's the problem we have to deal with in systemd-homed. What's worse, the account and session PAM stacks that SSH runs have a NULL conversation function installed, and hence cannot ask questions either.
Add comment