On Sat, Jul 16, 2011 at 5:22 PM, Theo de Raadt <dera...@cvs.openbsd.org> wrote: >> It does look like an open source result of some talented people, not >> an OpenBSD or BSD specific result. > > OpenSSH happened as a *direct result* of the types of decisions that > OpenBSD developers make.
Hi, Theo. That would be a compelling point if those decisions were automatically good ones. Simply being "the types of decisions that OpenBSD developers make" is not automatically a selling point, as evidenced by the relatively small market share of OpenBSD itself. I'm gong to dig into some history here. The result of "the types of decisions that OpenBSD developers make" are precisely why it is marginalized. The core technology is robust and excellent, but the featureset is not only limited, but actively dangerous. I'll explain why: this gots into some serious way-back history, but I'm not seeing any change. First is the amazing foolishness of having the default key generators accept blank passphrases without even requiring a special command line option. Second is lack of a reliable key expiration mechanism. Once a blank passphrase is in use, clearing them up is very difficult to detect and very awkward to revoke the keys. These are deadly aspects of the SSH protocol and toolkits that could, and should, have been addressed a decade ago, even before OpenSSH existed. The result is that I've personally had one hell of a time getting people off of less technologically secure tools, such as HTTPS access for Subverson which stores passwords in clear text on UNIX and Linux clients. This tool has SSH based access available to avoid the UNIX or Linux client password storage of HTTPS, but lacks an integral chroot cage or dedicated shell to restrict the users: the results are various weird, homegrown integrations. (Sourceforge uses one, and it's messy due to the lack of chroot cage compatible integration for Subversion.) Git does a better job of this, by the way, which is a good reason to prefer it. But I've dealt with.... 6 such source control integration efforts in the last 5 years, and it's painful to deal with the passphrase free keys and having to hand-build an expiration mechanism *eveyr single time*, even if I do keep my old notes. This could be eased by client side software changes, such as refusing to accept a blank password without a special command line option or user privilege, or even a setting in ssh_config to block such behavior. If a client can override that, then it's their problem, but the lack of any significant barrier to generating such keys is a long standing issue I've had to clean up after again, and again, and again. This is compounded by the longstanding refusal to accept chroot cage integration for SSH or SCP. (Yes, it's me: I was one of the people publishing such patches over a decade ago.) Debian has actually provided some tools for helping set that up, and they're quite useful for at least raising the bar for clients with locally authorized access to escape their cages. SFTP does a better job of it, and its relatively new built-in chroot cages are welcome. But the chroot cages for SSH are long-desired for Subversion and CVS repository access, and software regression testing environments. (By the way, the better security models of "git" with its dedicated shell and good key management tools well justify switching to it from CVS or Subversion, along with its vastly better "merge" behavior.) If we couple all of those decisions, mostly policy decisions, with the longstanding incapability to transfer symlinks as symlinks, rather than as the targets of the symlink, by both SFTP and SCP, and the direct result of those decisions doesn't look so hot, even though the underlying protocol and implementation in OpenSSH have much to recommend them. This last one is actually built into the RFC's, but if a new RFC is needed, then it's about time. The result is that I'd *rather* trust the end-to-end encryption of the underlying SSH protocol. But the missing basic security features, whose absence is either tacitly accepted (such as making passphrase keys more difficult to use), or a matter of deliberate policy (such as refusal to work with chroot cages for SSH or SCP) have seriuosly impeded the use and security of OpenSSH itself. So I have some longstanding, and I think well-founded, concerns about "the types of decisions that OpenBSD developers make".
