Post AhUM98ORceU5UonowK by enkiusz@is-a.cat
(DIR) More posts by enkiusz@is-a.cat
(DIR) Post #AhUM92Mo1pbmnzzQYK by pid_eins@mastodon.social
2024-05-02T07:34:18Z
0 likes, 0 repeats
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…
(DIR) Post #AhUM93ZxWPiwZ59Rh2 by pid_eins@mastodon.social
2024-05-02T07:37:07Z
0 likes, 0 repeats
… 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.An effect of this is that certain things that…
(DIR) Post #AhUM94TcBUF9LhBtRY by pid_eins@mastodon.social
2024-05-02T07:39:44Z
0 likes, 0 repeats
…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)…
(DIR) Post #AhUM95SaWn14OniaTw by pid_eins@mastodon.social
2024-05-02T07:42:39Z
0 likes, 0 repeats
… 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).
(DIR) Post #AhUM966I9Am8NwIIMq by pid_eins@mastodon.social
2024-05-02T07:45:57Z
0 likes, 0 repeats
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.
(DIR) Post #AhUM96nBZh5QWyMYE4 by pid_eins@mastodon.social
2024-05-02T07:47:52Z
0 likes, 0 repeats
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…
(DIR) Post #AhUM97JncRAsA7cb3o by pid_eins@mastodon.social
2024-05-02T07:50:27Z
0 likes, 0 repeats
… 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: 1. if the home dir alreads has been unlocked, you get the shell directly as on classic UNIX systems.2. 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.
(DIR) Post #AhUM980h2xUAJ9gqv2 by pid_eins@mastodon.social
2024-05-02T07:51:26Z
0 likes, 0 repeats
That's the gist of it at least. It's a bit more involved IRL.Anyway, that's all for today, let's see if I can keep this up and post installment #9 soon.
(DIR) Post #AhUM98ORceU5UonowK by enkiusz@is-a.cat
2024-05-02T08:17:55Z
0 likes, 0 repeats
@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
(DIR) Post #AhUM99DqXXbK4Eqs3k by pid_eins@mastodon.social
2024-05-02T08:27:08Z
0 likes, 1 repeats
@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.