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