<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Improving Upgrade Success Rate for OpenSSH</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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).</FONT></P>
<P><FONT SIZE=2>Anyway, it's a thought. </FONT>
</P>
<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Dan Kaminsky</FONT>
<BR><FONT SIZE=2>To: Brian Hatch</FONT>
<BR><FONT SIZE=2>Cc: Damien Miller; secureshell@securityfocus.com; openssh-unix-dev@mindrot.org</FONT>
<BR><FONT SIZE=2>Sent: 1/25/02 4:23 AM</FONT>
<BR><FONT SIZE=2>Subject: Improving Upgrade Success Rate for OpenSSH</FONT>
</P>
<P><FONT SIZE=2>Brian--</FONT>
</P>
<P><FONT SIZE=2> Hmmm? My administrative process? *maniacal grin*</FONT>
</P>
<P><FONT SIZE=2>===</FONT>
<BR><FONT SIZE=2>Dan@EFFUGAS ~</FONT>
<BR><FONT SIZE=2>$ ssh -o ProxyCommand="ssh root@%h /root/openssh/sshd -i"</FONT>
<BR><FONT SIZE=2>effugas@10.0.1.11</FONT>
<BR><FONT SIZE=2>root@10.0.1.11's password:</FONT>
<BR><FONT SIZE=2>effugas@10.0.1.11's password:</FONT>
<BR><FONT SIZE=2>FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3 13:44:59 GMT 2001</FONT>
<BR><FONT SIZE=2>$</FONT>
<BR><FONT SIZE=2>===</FONT>
</P>
<P><FONT SIZE=2> But that's besides the point. What I can do for myself is one</FONT>
<BR><FONT SIZE=2>thing,</FONT>
<BR><FONT SIZE=2>but it doesn't do a whit of good when I'm connecting to other people's</FONT>
<BR><FONT SIZE=2>servers. The more they screw up, the more I have to assume there hasn't</FONT>
<BR><FONT SIZE=2>been a MITM. And I have to make that assumption pretty regularly; sure,</FONT>
<BR><FONT SIZE=2>we've been using SSH since before it was cool, but they haven't.</FONT>
</P>
<P><FONT SIZE=2> It's more than unproductive for me to just whine about other people</FONT>
<BR><FONT SIZE=2>not</FONT>
<BR><FONT SIZE=2>knowing some shibboleth to render SSH functional with previous keys</FONT>
<BR><FONT SIZE=2>intact;</FONT>
<BR><FONT SIZE=2>it's poor administrative process. Patching SSH is a very roundabout way</FONT>
<BR><FONT SIZE=2>of</FONT>
<BR><FONT SIZE=2>me administering other people's machines. The easier it is for others</FONT>
<BR><FONT SIZE=2>to</FONT>
<BR><FONT SIZE=2>upgrade successfully, the more likely they will, and the safer I'll be.</FONT>
<BR><FONT SIZE=2>Beyond key fade, older versions of SSH are to no small degree the</FONT>
<BR><FONT SIZE=2>thunderclouds rumbling in our collective future, and doing even small</FONT>
<BR><FONT SIZE=2>things</FONT>
<BR><FONT SIZE=2>to alleviate that makes me sleep easier.</FONT>
</P>
<P><FONT SIZE=2> I'm really thinking now about a small check during ./configure</FONT>
<BR><FONT SIZE=2>that</FONT>
<BR><FONT SIZE=2>would compare the keys to be loaded by the compiled SSHD against</FONT>
<BR><FONT SIZE=2>whichever</FONT>
<BR><FONT SIZE=2>keys were being hosted on 127.0.0.1:22. Configure wouldn't necessarily</FONT>
<BR><FONT SIZE=2>fail, but it might end with:</FONT>
</P>
<P><FONT SIZE=2>WARNING: This build of the SSH server will serve a different set of</FONT>
<BR><FONT SIZE=2>server</FONT>
<BR><FONT SIZE=2>identity keys than the server presently deployed on this host. This</FONT>
<BR><FONT SIZE=2>will</FONT>
<BR><FONT SIZE=2>cause clients to be unable to recognize this host, and force them to</FONT>
<BR><FONT SIZE=2>take a</FONT>
<BR><FONT SIZE=2>"leap of faith" that they are still legitimately connecting to your</FONT>
<BR><FONT SIZE=2>server</FONT>
<BR><FONT SIZE=2>rather than a "man in the middle". The more used to these leaps your</FONT>
<BR><FONT SIZE=2>users</FONT>
<BR><FONT SIZE=2>are, the less security there will be in your identity keys at all. To</FONT>
<BR><FONT SIZE=2>continue using the present keys, you may want to try</FONT>
<BR><FONT SIZE=2>adding --sysconfdir="/path" to your invocation of configure, replacing</FONT>
<BR><FONT SIZE=2>"path" with the location of the keys presently being served(most likely,</FONT>
<BR><FONT SIZE=2>/etc or /etc/ssh).</FONT>
</P>
<P><FONT SIZE=2> ...only possibly a bit less verbose. This has the huge advantage of</FONT>
<BR><FONT SIZE=2>not</FONT>
<BR><FONT SIZE=2>requiring prior knowledge of --with-upgrade to prevent a key fade.</FONT>
</P>
<P><FONT SIZE=2> As for MD5 passwords...well, that codebase needs to be taken out of</FONT>
<BR><FONT SIZE=2>preprocessor hell, if I remember correctly. If password type was</FONT>
<BR><FONT SIZE=2>contained</FONT>
<BR><FONT SIZE=2>within sshd_config, and all possible auth_passwd methods were just</FONT>
<BR><FONT SIZE=2>compiled</FONT>
<BR><FONT SIZE=2>in, the system password type would persist from build to build in the</FONT>
<BR><FONT SIZE=2>config</FONT>
<BR><FONT SIZE=2>and wouldn't otherwise pollute the rebuilding process.</FONT>
</P>
<P><FONT SIZE=2> Is there any reasonable, cross platform way of determining the</FONT>
<BR><FONT SIZE=2>master</FONT>
<BR><FONT SIZE=2>SSHD's PID from a child subshell?</FONT>
</P>
<P><FONT SIZE=2>--Dan</FONT>
</P>
<BR>
<P><FONT SIZE=2>_______________________________________________</FONT>
<BR><FONT SIZE=2>openssh-unix-dev@mindrot.org mailing list</FONT>
<BR><FONT SIZE=2><A HREF="http://www.mindrot.org/mailman/listinfo/openssh-unix-dev" TARGET="_blank">http://www.mindrot.org/mailman/listinfo/openssh-unix-dev</A></FONT>
</P>
<CODE><FONT SIZE=3><BR>
<BR>
***************************************************************************************<BR>
WARNING: All e-mail sent to and from this address will be received or<BR>
otherwise recorded by the A.G. Edwards corporate e-mail system and is<BR>
subject to archival, monitoring or review by, and/or disclosure to,<BR>
someone other than the recipient.<BR>
***************************************************************************************<BR>
</FONT></CODE></BODY>
</HTML>