systemd: make systemd-ssh-generator work#372979
Conversation
29ab9ba to
23b36d5
Compare
23b36d5 to
da9dd95
Compare
phaer
left a comment
There was a problem hiding this comment.
Very nice to see this coming to upstream NixOS, thank you very much!
There was a problem hiding this comment.
I don't think there's a proper issue about this yet, but systemd itself would also support passing credentials via kernel params which could be very useful for VMs. But that doesn't work with our current systemd-in-stage-1 implementation. @ElvishJerricco wrote a reproducer for that in https://gist.github.com/ElvishJerricco/dca95eb4ea9fc410bd525c3b15b68fdd
da9dd95 to
cf51558
Compare
r-vdp
left a comment
There was a problem hiding this comment.
Overall this looks good, I will try to test it out over the next days.
63585df to
3ae5dfe
Compare
|
rebased onto latest staging to get around bluez and linux build failure when building |
We need to patch systemd to make systemd-ssh-generator(8) work: - systemd doesn't follow symlinks when checking for a packaged [email protected] unit - systemd tries to link the ssh config dropins by default with tmpfiles to /usr, that is not possible, so we include the snippet manually.
3ae5dfe to
28c2232
Compare
|
We should probably rename |
28c2232 to
ea8c28a
Compare
philiptaron
left a comment
There was a problem hiding this comment.
I have a few questions about the systemd service files I'd like to understand before ✅, but I'm inclined to merge after that.
The one piece that looks most scary to me is the new tmpfiles.d configuration, which is doing more than just SSH stuff.
There was a problem hiding this comment.
https://linux.die.net/man/8/sshd:
-iSpecifies that sshd is being run from inetd(8). sshd is normally not run from inetd because it needs to generate the server key before it can respond to the client, and this may take tens of seconds. Clients would have to wait too long if the key was regenerated every time. However, with small key sizes (e.g. 512) using sshd from inetd may be feasible.
This documentation makes me confused. I'm assuming socket activation is inetd-like, and this is the flag that's different. However the rest (about waiting too long, generating keys) is odd.
There was a problem hiding this comment.
I'm also confused by this, not sure if host keys are meant?
Since those are generated a single time
nixos/tests/systemd-ssh-proxy.nix
Outdated
nixos/tests/systemd-ssh-proxy.nix
Outdated
There was a problem hiding this comment.
I love this worked example of how to do this. One of the huge benefits of tests is just showing how to do things.
There was a problem hiding this comment.
It would have been nice to avoid using an ISO for this. That's a very large build to be pushing to the cache that no one will ever use (yes, Hydra pushes these intermediate builds).
Also, this is technically nested virtualisation (double nested if the builder itself is a VM), and I'm not sure if we can take that as a given on the hardware we use for Hydra builders?
There was a problem hiding this comment.
I believe we can test this functionality with nixos-containers instead. That would avoid both problems. I'll give it a look.
There was a problem hiding this comment.
The commit introducing this patch says:
systemd tries to link the ssh config dropins by default with tmpfiles to /usr, that is not possible, so we include the snippet manually.
There was a problem hiding this comment.
The commit introducing this patch says:
systemd doesn't follow symlinks when checking for a packaged
[email protected]unit
There was a problem hiding this comment.
Future: sshdconfdir (note the d) is about https://github.com/systemd/systemd/blob/3a15daf4402ba2e35c27f21339e987d89f4f8a97/src/userdb/20-systemd-userdb.conf.in
Make sure SSH authorized keys recorded in user records can be consumed by SSH
This enables systemd-ssh-generator to find the sshd binary.
philiptaron
left a comment
There was a problem hiding this comment.
I'm planning on approving after the patch to do only the SSH provisioning (not the hosts or MOTD stuff) lands.
nixos/modules/programs/ssh.nix
Outdated
There was a problem hiding this comment.
There was a problem hiding this comment.
We could (and I kind of think maybe we should?) patch this:
This enables provisioning of root ssh keys with systemd credentials (e.g. passed in via smbios strings or kernel params)
philiptaron
left a comment
There was a problem hiding this comment.
Test passes, and tested again rebased onto latest staging.
I did notice a few odd things:
- There are i686 stdenv things in the closure of the test!
- There are musl things in the closure of the test!
- The test ends successfully, but in the last messages on screen is
vm-test-run-systemd-ssh-proxy> virthost # [ 30.559645] systemd[1]: Failed to start SSH per-connection Daemon (PID 1077/UID 1000). vm-test-run-systemd-ssh-proxy> virthost # [ 30.560918] systemd[1]: session-1.scope: Deactivated successfully. vm-test-run-systemd-ssh-proxy> virthost # [ 30.563206] systemd-logind[728]: Removed session 1.
I didn't debug further.
|
I think this may have broken more NixOS tests. I've found an instance of this in the GitLab test which blocks the channel #398846. It's likely worth checking if this affects other tests as well. |
|
@sternenseemann thanks for noticing! I've had a quick look with a few ripgreps and the only test which looked like it could have been affected was |
SSH key generation was split out into its own systemd service in #372979, but dependent service definitions weren't updated. The `apply-ec2-data` service needs to run before SSH key generation, as it fetches host keys defined in ec2 user data and these keys should take priority over generating new ones. Currently, the ordering doesn't specify which should run first of `apply-ec2-data` and `sshd-keygen`; in practice it seems that `sshd-keygen` often wins the race, though. Update the dependencies so that `apply-ec2-data` always runs first.
SSH key generation was split out into its own systemd service in #372979, but dependent service definitions weren't updated. The `apply-ec2-data` service needs to run before SSH key generation, as it fetches host keys defined in ec2 user data and these keys should take priority over generating new ones. Currently, the ordering doesn't specify which should run first of `apply-ec2-data` and `sshd-keygen`; in practice it seems that `sshd-keygen` often wins the race, though. Update the dependencies so that `apply-ec2-data` always runs first. (cherry picked from commit d9ac3ba)
SSH key generation was split out into its own systemd service in NixOS#372979, but dependent service definitions weren't updated. The `apply-ec2-data` service needs to run before SSH key generation, as it fetches host keys defined in ec2 user data and these keys should take priority over generating new ones. Currently, the ordering doesn't specify which should run first of `apply-ec2-data` and `sshd-keygen`; in practice it seems that `sshd-keygen` often wins the race, though. Update the dependencies so that `apply-ec2-data` always runs first. (cherry picked from commit d9ac3ba)
Makes systemd-ssh-generator and systemd-ssh-proxy work on NixOS.
I successfully built this and ran
nixosTests.systemd-ssh-proxyandnixosTests.openssh.I also built the minimal iso and manually tested the vsock feature with a qemu vm.
closes #371191
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.