Tools: OpenSSH 3.6

Submitted by Jeremy

on March 30, 2003 - 4:03pm

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?

Anonymous

March 31, 2003 - 11:42pm

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

Anonymous

April 1, 2003 - 1:06am

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

Anonymous

April 3, 2003 - 1:30pm

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

flugstadp

April 7, 2003 - 8:25am

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.

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

Anonymous

April 8, 2003 - 12:01pm

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 ?

Anonymous

April 1, 2003 - 1:13am

Do you know a valid, more secure and yet still free replacement ?

more secure lsh/ssh

coriordan

April 1, 2003 - 6:26am

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?

Anonymous

April 2, 2003 - 7:14am

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...

Anonymous

April 3, 2003 - 9:12am

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

Anonymous

April 3, 2003 - 1:17pm

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.