Improving Upgrade Success Rate for OpenSSH

[Lacoss-Arnold, Jason]

While this may have some benefit, if you worried about busineses at all, you
may get more benefit by working on the Solaris packaging scripts and HP
depot scripts that I think I saw on a TODO list in the code.

My rational is this: most businesses of any size at all don't compile ssh on
every server that they deploy it to (and in fact rarely have compilers on a
lot of them).  Instead, we build and package it on one server, then deploy
it to a few hundred others.  One thing that we've been careful to do in
building our package is to put the keys in a location that won't be deleted
when the package is removed (i.e. for an upgrade) and also check during
package install to see if the keys have been left in one of the places where
we tend to leave old keys (due to poor standards during previous roll-outs).

Anyway, it's a thought. 

-----Original Message-----
From: Dan Kaminsky
To: Brian Hatch
Cc: Damien Miller; secureshell at securityfocus.com;
openssh-unix-dev at mindrot.org
Sent: 1/25/02 4:23 AM
Subject: Improving Upgrade Success Rate for OpenSSH

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


_______________________________________________
openssh-unix-dev at mindrot.org mailing list
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev


***************************************************************************************
WARNING:  All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.
***************************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020125/00d761f2/attachment.html