Markus Friedl announced the release of OpenSSH 3.6 today, five months after the release of version 3.5 [story]. Today's release includes a number of enhancements, including RSA blinding to avoid potential timing attacks against RSA keys, bandwidth limiting for 'scp', and a progress bar and improved error handling for 'sftp'.
OpenSSH 3.6 is available for download now, and will also be part of the upcoming OpenBSD 3.3 release available on May 1'st. Read on for the release announcement, including full details as to what's new in this verison.
From: Markus Friedl To: misc Subject: OpenSSH 3.6 released Date: Mon, 31 Mar 2003 14:48:54 +0200 OpenSSH 3.6 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support to the project, especially those who contributed source and bought T-shirts or posters. We have a new design of T-shirt available, more info on http://www.openbsd.org/tshirts.html#18 For international orders use http://https.openbsd.org/cgi-bin/order and for European orders, use http://https.openbsd.org/cgi-bin/order.eu Changes since OpenSSH 3.5: ============================ * RSA blinding is now used by ssh(1), sshd(8) and ssh-agent(1). in order to avoid potential timing attacks against the RSA keys. Older versions of OpenSSH have been using RSA blinding in ssh-keysign(1) only. Please note that there is no evidence that the SSH protocol is vulnerable to the OpenSSL/TLS timing attack described in http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf * ssh-agent(1) optionally requires user confirmation if a key gets used, see '-c' in ssh-add(1). * sshd(8) now handles PermitRootLogin correctly when UsePrivilegeSeparation is enabled. * sshd(8) now removes X11 cookies when a session gets closed. * ssh-keysign(8) is disabled by default and only enabled if the new EnableSSHKeysign option is set in the global ssh_config(5) file. * ssh(1) and sshd(8) now handle 'kex guesses' correctly (key exchange guesses). * ssh(1) no longer overwrites SIG_IGN. This matches behaviour from rsh(1) and is used by backup tools. * setting ProxyCommand to 'none' disables the proxy feature, see ssh_config(5). * scp(1) supports add -1 and -2. * scp(1) supports bandwidth limiting. * sftp(1) displays a progressmeter. * sftp(1) has improved error handling for scripting. Checksums: ========== - MD5 (openssh-3.6p1.tar.gz) = 72ef1134d521cb6926c99256dad17fe0 - MD5 (openssh-3.6.tgz) = 758822b888c5c3f83a98045aef904254 Reporting Bugs: =============== - please read http://www.openssh.com/report.html and http://bugzilla.mindrot.org/ OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller and Ben Lindstrom.
software announcements?
Regular userspace software announcements on KernelTrap? Or you could just syndicate Freshmeat... Anyways, OpenSSH has had too many security holes for me to trust the thing.
GNU lsh && rsync
There is a GNU lsh you know... it's not feature complete but works wonders. And please use rsync instead of scp, it is more modern and can resume among other things.
There are other free ssh alte
There are other free ssh alternatives too, fact is they don't have the penetration of OpenSSH and there might be some reason to that.
The sad thing is that OpenSSH is a BSD licensed product that anyone can use for whatever purpose (hurray, -real- free software) and very few commercial vendors are making use of it. Cisco et al's sshd is total shit, and costs more - when they could and _should_ just be using something which is already available for them to use freely, without even documenting or releasing any changes for their proprietary hardware. Some vendors (cabletron/enterasys) appear to be incorporating sshd's more regularly [my guess if from OpenSSH], but it's taking really goddamn long.
lsh is maybe useful for heterogenity, but outside of that it's not too useful imnsho. GNU+GPL requires that people reinvent the wheel, just like commercial software, because it doesn't grant others enough rights. OpenSSH (or lsh) would never have happened if ssh had remained unencumbered, and if OpenSSH had existed before lsh, I doubt it would have occurred either. Yay wheelv39241
OpenSSH on RTOS is painful
Cisco runs IOS, which AFAIK, is a proprietary embedded real-time OS. Typically RTOS's don't have process space like Linux/*nix, but are essentially a single process space with multiple threads. Porting OpenSSH to such an OS is *extremely* painful, as they make use of many Unixisms, global static variables and so on, that just can't be done in a single address space, multi threaded environment (I know, I've done it).
I haven't see a reasonable thread-safe "ssh library" yet - lsh may be it, but the license precludes it from being used by Cisco (or anyone else like that).
Your license rant
Saying that the GPL prevents vendors from using those products in their own operating systems is FUD. Why would Sun want to release a binary for their sshd, but be so afraid of releasing the source to sshd that they would rather not use it at all? Doesn't make sense.
Of course, that has just about nothing to do with OpenSSH. So why did you bring it up?
What do you use instead ?
Do you know a valid, more secure and yet still free replacement ?
more secure lsh/ssh
GNU lsh can combine user-specified random data with system-provided
random data. Good when you don't trust/own/know the system you're
logged into.
This also means that it can provide *reasonably* secure communications
even when running on a system without a /dev/random.
Code security is a trade off: It's far less likely to get hacked since
fewer people use it, a hack wouldn't be as useful. The other side is
that fewer users means fewer testers.
Here's the website:
http://www.lysator.liu.se/~nisse/lsh/
Why?
Why do you think OpenSSH has had so many security holes? Is it because the authors are not competent? Is it because the problem they are trying to solve is a very difficult problem? Are other ssh implementations any less vulnerable?
well...
In some 6+ years there has only been one remote hole in OpenSSH (yes i am repeating the blatantly obvious OpenBSD logo). I don't see how anyone can say that *SSH is unsafe though. What else would you use? telnetd? Anyways, if 1 exploit is 1 to many for your trust, then I really have no idea what else you would use, because about _EVERY_ server in the world has, if only for a few hours, been vulnerable to something.
FUD
baloney. OpenSSH has an extremely good track record for a network service, which actually pretty much requires root [network port ACL's could eliminate the port binding - but it's still dishing out _shells_, including potentially a legitimate root shell, that's hard to really have an absolute unpriveleged model for]. Not to mention, the last multiplatform ssh problem (see rapid7 advisory) did not even effect OpenSSH.
3.6.1 already out
FYI, 3.6.1 is already out. There seems to have been an interoperability issue with other SSH implementations.