Improving Upgrade Success Rate for OpenSSH

[Dan Kaminsky]

Brian--

    Hmmm?  My administrative process?  *maniacal grin*

===
Dan at EFFUGAS ~
$ ssh -o ProxyCommand="ssh root@%h /root/openssh/sshd -i" effugas at 10.0.1.11
root at 10.0.1.11's password:
effugas at 10.0.1.11's password:
FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec  3 13:44:59 GMT 2001
$
===

    But that's besides the point.  What I can do for myself is one thing,
but it doesn't do a whit of good when I'm connecting to other people's
servers.  The more they screw up, the more I have to assume there hasn't
been a MITM.  And I have to make that assumption pretty regularly; sure,
we've been using SSH since before it was cool, but they haven't.

     It's more than unproductive for me to just whine about other people not
knowing some shibboleth to render SSH functional with previous keys intact;
it's poor administrative process.  Patching SSH is a very roundabout way of
me administering other people's machines.  The easier it is for others to
upgrade successfully, the more likely they will, and the safer I'll be.
Beyond key fade, older versions of SSH are to no small degree the
thunderclouds rumbling in our collective future, and doing even small things
to alleviate that makes me sleep easier.

      I'm really thinking now about a small check during ./configure that
would compare the keys to be loaded by the compiled SSHD against whichever
keys were being hosted on 127.0.0.1:22.  Configure wouldn't necessarily
fail, but it might end with:

WARNING:  This build of the SSH server will serve a different set of server
identity keys than the server presently deployed on this host.  This will
cause clients to be unable to recognize this host, and force them to take a
"leap of faith" that they are still legitimately connecting to your server
rather than a "man in the middle".  The more used to these leaps your users
are, the less security there will be in your identity keys at all.  To
continue using the present keys, you may want to try
adding --sysconfdir="/path" to your invocation of configure, replacing
"path" with the location of the keys presently being served(most likely,
/etc or /etc/ssh).

    ...only possibly a bit less verbose.  This has the huge advantage of not
requiring prior knowledge of --with-upgrade to prevent a key fade.

    As for MD5 passwords...well, that codebase needs to be taken out of
preprocessor hell, if I remember correctly.  If password type was contained
within sshd_config, and all possible auth_passwd methods were just compiled
in, the system password type would persist from build to build in the config
and wouldn't otherwise pollute the rebuilding process.

    Is there any reasonable, cross platform way of determining the master
SSHD's PID from a child subshell?

--Dan