@GrahamcOfBorg eval

I'd prefer not adding setuid binaries unless it's absolutely necessary.

Does this configure where the ssh client expects to find this binary on a remote server? Or is it where a server expects to find this binary on itself?

@alyssais

Does this configure where the ssh client expects to find this binary on a remote server? Or is it where a server expects to find this binary on itself?

It's where the client expects to find ssh-keysign on the local machine.

@edolstra

I'd prefer not adding setuid binaries unless it's absolutely necessary.

I'm quite purposely not enabling the setuid wrapper by default, and unless we're committing to "host-based authentication doesn't work on NixOS", it is indeed necessary. If we're committing to making functionality unusable for the sake of decreasing the SUID binary count, I'd rather start with gnome-keyring-daemon than OpenSSH, and review all the others.

It's also worth noting that even with the wrapper enabled, it is entirely inactive without EnableSSHKeysign yes in global ssh_config.

Could we instead pass this value in as an SSH configuration option, in the /etc/ssh/ssh_config file?

@grahamc

Could we instead pass this value in as an SSH configuration option, in the /etc/ssh/ssh_config file?

That would cause every unpatched OpenSSH to crash:

[root@platypus:/etc/ssh]# echo Foo bar >> ssh_config
[root@platypus:/etc/ssh]# ssh anywhere
/etc/ssh/ssh_config: line 15: Bad configuration option: foo
/etc/ssh/ssh_config: terminating, 1 bad configuration options

You can use IgnoreUnknown Foo, and then non-patched versions will just ignore it. (Not that I think it’s a good idea.)

You can use IgnoreUnknown Foo, and then non-patched versions will just ignore it. (Not that I think it’s a good idea.)

Okay, so I guess that's an option. There doesn't seem to be a sensible distro-independent default, anyhow. It lives at /usr/lib/openssh/ssh-keysign on Debian, /usr/lib/ssh/ssh-keysign on Arch, /usr/libexec/openssh/ssh-keysign on Fedora, etc.

If anything, I'm tending towards either "just take it from PATH" or "just take it from SSH client config" to quiet the arguments. I was reluctant to do either because the normal mechanism hardcodes a root-controlled purpose-named location, but as far as I can tell ssh-keysign doesn't really receive anything sensitive, certainly no more so than whoever controls SSH_AUTH_SOCK.
This doesn't actually make anything work on non-NixOS without user intervention either, but at least rids us of the /run/wrappers boogeyman. We can even {default,fall back} to the Nix store path as we do now and remain compatible with the running-as-root case without additional configuration, if anyone really wants to push that case.

I'm expecting using PATH to be fairly uncontroversial, and will default to merging in a week (2019-08-10) if nobody objects.