Considering shipping ssh-keysign non-setuid

[Colin Watson]

In light of things like 
https://github.com/0xdeadbeefnetwork/ssh-keysign-pwn and the general 
attack surface of set-id, I'm considering changing Debian's OpenSSH 
packaging to ship ssh-keysign non-setuid, and patching the documentation 
to tell users that they need to make it setuid root (using a 
Debian-specific tool that causes that kind of change to be preserved 
across upgrades) if they want to use host-based authentication.  My 
sense is that host-based authentication is quite niche these days and 
that it already involves a certain amount of specialized setup anyway.

As far as upgrade considerations go, ssh-keysign is client-side, so 
there should be no risk of making people's machines inaccessible on 
upgrade.  We could possibly detect whether `EnableSSHKeysign yes` is 
already set in the client configuration and preserve the setuid bit in 
that case.

Would the upstream developers have any objection to this configuration?  
It would be a difference from what `make install` does and it's possible 
that it might result in the odd stray support request, so it seemed 
polite to check.

Alternatively (or additionally), I'm considering splitting ssh-keysign 
out to a separate `openssh-keysign` package, since most users don't need 
to have it installed at all.

It looks as though Fedora does both these things (a separate package, 
and no setuid bit).  They seem to have no documentation of how to make 
ssh-keysign persistently setuid on systems that require it, at least not 
in their packaging.

Thanks,

-- 
Colin Watson (he/him)                              [cjwatson at debian.org]