|
|
Subscribe / Log in / New account

OpenSSH 5.4 released

From:  Damien Miller <djm-AT-cvs.openbsd.org>
To:  lwn-AT-lwn.net
Subject:  Announce: OpenSSH 5.4 released
Date:  Sun, 7 Mar 2010 19:05:58 -0700 (MST)
Message-ID:  <201003080205.o2825wof025763@cvs.openbsd.org>


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

Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed code
or patches, reported bugs, tested snapshots or donated to the project.
More information on donations may be found at:
http://www.openssh.com/donations.html

This is a major feature and bugfix release.

Changes since OpenSSH 5.3
=========================

Features:

 * After a transition period of about 10 years, this release disables
   SSH protocol 1 by default. Clients and servers that need to use the
   legacy protocol must explicitly enable it in ssh_config / sshd_config
   or on the command-line.

 * Remove the libsectok/OpenSC-based smartcard code and add support for
   PKCS#11 tokens. This support is automatically enabled on all
   platforms that support dlopen(3) and was inspired by patches written
   by Alon Bar-Lev. Details in the ssh(1) and ssh-add(1) manpages.

 * Add support for certificate authentication of users and hosts using a
   new, minimal OpenSSH certificate format (not X.509). Certificates
   contain a public key, identity information and some validity
   constraints and are signed with a standard SSH public key using
   ssh-keygen(1). CA keys may be marked as trusted in authorized_keys
   or via a TrustedUserCAKeys option in sshd_config(5) (for user
   authentication), or in known_hosts (for host authentication).

   Documentation for certificate support may be found in ssh-keygen(1),
   sshd(8) and ssh(1) and a description of the protocol extensions in
   PROTOCOL.certkeys.

 * Added a 'netcat mode' to ssh(1): "ssh -W host:port ..." This connects
   stdio on the client to a single port forward on the server. This
   allows, for example, using ssh as a ProxyCommand to route connections
   via intermediate servers. bz#1618

 * Add the ability to revoke keys in sshd(8) and ssh(1). User keys may
   be revoked using a new sshd_config(5) option "RevokedKeys". Host keys
   are revoked through known_hosts (details in the sshd(8) man page).
   Revoked keys cannot be used for user or host authentication and will
   trigger a warning if used.

 * Rewrite the ssh(1) multiplexing support to support non-blocking
   operation of the mux master, improve the resilience of the master to
   malformed messages sent to it by the slave and add support for
   requesting port- forwardings via the multiplex protocol. The new
   stdio-to-local forward mode ("ssh -W host:port ...") is also
   supported. The revised multiplexing protocol is documented in the
   file PROTOCOL.mux in the source distribution.

 * Add a 'read-only' mode to sftp-server(8) that disables open in write
   mode and all other fs-modifying protocol methods. bz#430

 * Allow setting an explicit umask on the sftp-server(8) commandline to
   override whatever default the user has. bz#1229

 * Many improvements to the sftp(1) client, many of which were
   implemented by Carlos Silva through the Google Summer of Code
   program:
   - Support the "-h" (human-readable units) flag for ls
   - Implement tab-completion of commands, local and remote filenames
   - Support most of scp(1)'s commandline arguments in sftp(1), as a
     first step towards making sftp(1) a drop-in replacement for scp(1).
     Note that the rarely-used "-P sftp_server_path" option has been
     moved to "-D sftp_server_path" to make way for "-P port" to match
     scp(1).
   - Add recursive transfer support for get/put and on the commandline

 * New RSA keys will be generated with a public exponent of RSA_F4 ==
   (2**16)+1 == 65537 instead of the previous value 35.

 * Passphrase-protected SSH protocol 2 private keys are now protected
   with AES-128 instead of 3DES. This applied to newly-generated keys
   as well as keys that are reencrypted (e.g. by changing their
   passphrase).

Bugfixes:

 * Hold authentication debug messages until after successful
   authentication. Fixes a minor information leak of environment
   variables specified in authorized_keys if an attacker happens to
   know the public key in use.
 * When using ChrootDirectory, make sure we test for the existence of
   the user's shell inside the chroot and not outside (bz#1679)
 * Cache user and group name lookups in sftp-server using
   user_from_[ug]id(3) to improve performance on hosts where these
   operations are slow (e.g. NIS or LDAP). bz#1495
 * Fix problem that prevented passphrase reading from being interrupted
   in some circumstances; bz#1590
 * Ignore and log any Protocol 1 keys where the claimed size is not
   equal to the actual size.
 * Make HostBased authentication work with a ProxyCommand. bz#1569
 * Avoid run-time failures when specifying hostkeys via a relative
   path by prepending the current working directory in these cases.
   bz#1290
 * Do not prompt for a passphrase if we fail to open a keyfile, and log
   the reason why the open failed to debug. bz#1693
 * Document that the PubkeyAuthentication directive is allowed in a
   sshd_config(5) Match block. bz#1577
 * When converting keys, truncate key comments at 72 chars as per
   RFC4716. bz#1630
 * Do not allow logins if /etc/nologin exists but is not readable by the
   user logging in.
 * Output a debug log if sshd(8) can't open an existing authorized_keys.
   bz#1694
 * Quell tc[gs]etattr warnings when forcing a tty (ssh -tt), since we
   usually don't actually have a tty to read/set; bz#1686
 * Prevent sftp from crashing when given a "-" without a command.
   Also, allow whitespace to follow a "-". bz#1691
 * After sshd receives a SIGHUP, ignore subsequent HUPs while sshd
   re-execs itself. Prevents two HUPs in quick succession from resulting
   in sshd dying. bz#1692
 * Clarify in sshd_config(5) that StrictModes does not apply to
   ChrootDirectory. Permissions and ownership are always checked when
   chrooting. bz#1532
 * Set close-on-exec on various descriptors so they don't get leaked to
   child processes. bz#1643
 * Fix very rare race condition in x11/agent channel allocation: don't
   read after the end of the select read/write fdset and make sure a
   reused FD is not touched before the pre-handlers are called.
 * Fix incorrect exit status when multiplexing and channel ID 0 is
   recycled. bz#1570
 * Fail with an error when an attempt is made to connect to a server
   with ForceCommand=internal-sftp with a shell session (i.e. not a
   subsystem session). Avoids stuck client when attempting to ssh to
   such a service. bz#1606:
 * Warn but do not fail if stat()ing the subsystem binary fails. This
   helps with chrootdirectory+forcecommand=sftp-server and restricted
   shells. bz #1599
 * Change "Connecting to host..." message to "Connected to host."
   and delay it until after the sftp protocol connection has been
   established. Avoids confusing sequence of messages when the
   underlying ssh connection experiences problems. bz#1588
 * Use the HostKeyAlias rather than the hostname specified on the
   commandline when prompting for passwords. bz#1039
 * Correct off-by-one in percent_expand(): we would fatal() when trying
   to expand EXPAND_MAX_KEYS, allowing only EXPAND_MAX_KEYS-1 to
   actually work. Note that nothing in OpenSSH actually uses close to
   this limit at present. bz#1607
 * Fix passing of empty options from scp(1) and sftp(1) to the
   underlying ssh(1). Also add support for the stop option "--".
 * Fix an incorrect magic number and typo in PROTOCOL; bz#1688
 * Don't escape backslashes when displaying the SSH2 banner. bz#1533
 * Don't unnecessarily dup() the in and out fds for sftp-server. bz#1566
 * Force use of the correct hash function for random-art signature
   display as it was inheriting the wrong one when bubblebabble
   signatures were activated. bz#1611
 * Do not fall back to adding keys without constraints (ssh-add -c /
   -t ...) when the agent refuses the constrained add request. bz#1612
 * Fix a race condition in ssh-agent that could result in a wedged or
   spinning agent. bz#1633
 * Flush stdio before exec() to ensure that everying (motd
   in particular) has made it out before the streams go away. bz#1596
 * Set FD_CLOEXEC on in/out sockets in sshd(8). bz#1706

Portable OpenSSH Bugfixes:

 * Use system's kerberos principal name on AIX if it's available.
   bz#1583
 * Disable OOM-killing of the listening sshd on Linux. bz#1470
 * Use pkg-config for opensc config if it's available. bz#1160
 * Unbreak Redhat spec to allow building without askpass. bz#1677
 * If PidFile is set in sshd_config, use it in SMF init file. bz#1628
 * Print error and usage() when ssh-rand-helper is passed command-
   line arguments as none are supported. bz#1568
 * Add missing setsockopt() to set IPV6_V6ONLY for local forwarding
   with GatwayPorts=yes. bz#1648
 * Make GNOME 2 askpass dialog desktop-modal. bz#1645
 * If SELinux is enabled set the security context to "sftpd_t" before
   running the internal sftp server. bz#1637
 * Correctly check libselinux for necessary SELinux functions; bz#1713
 * Unbreak builds on Redhat using the supplied openssh.spec; bz#1731
 * Fix incorrect privilege dropping order on AIX that prevented
   chroot operation; bz#1567
 * Call aix_setauthdb/aix_restoredb at the correct times on AIX to
   prevent authentication failure; bz#1710

Checksums:
==========

 - SHA1 (openssh-5.4.tar.gz) = 1776832d902f7b4c7863afd41a5ec7a14efe95d6
 - SHA1 (openssh-5.4p1.tar.gz) = 2a3042372f08afb1415ceaec8178213276a36302

Reporting Bugs:
===============

- Please read http://www.openssh.com/report.html
  Security bugs should be reported directly to openssh@openssh.com

OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt,
Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and
Ben Lindstrom.




to post comments

OpenSSH 5.4 released

Posted Mar 8, 2010 15:10 UTC (Mon) by nix (subscriber, #2304) [Link]

Your headline is wrong. The release notes say it 'removes support for SSH
protocol 1 by default'; i.e., you can still turn it back on.

Dang! No HPN-SSH!

Posted Mar 8, 2010 16:57 UTC (Mon) by aaron (guest, #282) [Link] (13 responses)

I guess this happens every OpenSSH release, but I keep hoping they'll merge some of the patches from the Pittsburg Supercomputing Center.
(See http://www.psc.edu/networking/projects/hpn-ssh )
It's truly amazing how they help transfers over higher-latency links (i.e. any distance over a mile.) They also help local transfers a fair bit.
Unfortunately, for now, if you can't patch your own SSHd, you have to use commercial file-transfer software, a Riverbed, or RSA-SSHd.

Please, O pufferfish, strap on a jetpack!

Dang! No HPN-SSH!

Posted Mar 8, 2010 17:04 UTC (Mon) by alex (subscriber, #1355) [Link] (4 responses)

Is it by any chance because the OpenSSH team are worried about security
auditing code that goes from statically allocated to dynamically allocated
buffers?

Dang! No HPN-SSH!

Posted Mar 9, 2010 1:51 UTC (Tue) by BrucePerens (guest, #2510) [Link] (3 responses)

So, is the alternative to set the static buffers to 2MB?

Dang! No HPN-SSH!

Posted Mar 9, 2010 4:20 UTC (Tue) by djm (subscriber, #11651) [Link] (2 responses)

You are misinformed. There are no 2MB static buffers in OpenSSH.

Dang! No HPN-SSH!

Posted Mar 9, 2010 4:51 UTC (Tue) by BrucePerens (guest, #2510) [Link] (1 responses)

Yes, I know there are no 2MB static buffers. If you set the size of the communication buffers to 2MB, you would achieve the same speed increase as with the dynamic buffers used by the patch. That is, given a high-speed network connection. I don't know if this makes any difference for us folks with 3megabit/300kilobit DSL connections.

Dang! No HPN-SSH!

Posted Mar 9, 2010 11:04 UTC (Tue) by djm (subscriber, #11651) [Link]

The default session window in OpenSSH is 2MB already.

This limit is enough for a path with 5 seconds latency at your DSL speed.
Put differently, if your one-way path latency is 100ms then unmodified
OpenSSH's window size should only start restricting performance if your
transfer rate is ~160Mbit/s.

If you are on Internet2 and want to move files between continental USA and
Europe at gigabit speeds, then you might still want the HPN patches.

Dang! No HPN-SSH!

Posted Mar 9, 2010 4:24 UTC (Tue) by djm (subscriber, #11651) [Link] (2 responses)

We made some performance changes for high BDP links a few releases back,
which should have obviated the need for the HPN patches for all but the
highest BDP links. You should benchmark your connection to see if it
actually benefits from the HPN patches, which are quite intrusive.

The other component of the HPN patches that people sometimes ask for is the
ability to select a null cipher/MAC. We are not planning on implementing
that ever.

Dang! No HPN-SSH!

Posted Mar 9, 2010 11:51 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

Can you explain why it's a bad idea to be able to turn off secrecy? Sometimes I need to move a large file over the network, and the contents of that file are public (e.g. several TB of data published by the government). I don't care if someone sees this data, or even if they see me moving it, but I don't want anyone messing with it, thus I still need integrity. Of course I can move it with 'netcat' and then verify using sha1sum, but it'd sure be convenient if the default OS tools (ie OpenSSH) let me do this with a suitable incantation.

No-one is asking for this to be the default of course, but why can't we have it as an option without hacking the code?

Dang! No HPN-SSH!

Posted Mar 9, 2010 14:45 UTC (Tue) by andikleen (guest, #39006) [Link]

One of the main reasons for HPN is multi threaded MACing/encryption,
which is needed for fast enough links because a single core cannot do full performance otherwise.

And yes multi threading your application is typically intrusive, but
it's also very needed if it is CPU time intensive and
you want to keep up with modern systems.

Dang! No HPN-SSH!

Posted Mar 9, 2010 13:49 UTC (Tue) by andikleen (guest, #39006) [Link] (4 responses)

Fully agreed, it's really bizarre that OpenSSH is still single threaded even though cryptography takes so much CPU time. Basically you can't really use it on a serious network connection because of this problem. And in addition the small buffers also make it hard to use over a WAN.

I wonder if it's related to being developed on OpenBSD which is not exactly known for SMP scalability?

Perhaps the distros will use it some day at least, even if the maintainers can't get out of the 70ies.

Dang! No HPN-SSH!

Posted Mar 9, 2010 21:12 UTC (Tue) by djm (subscriber, #11651) [Link] (3 responses)

Yes, we are dinosaurs who would prefer to have to deal with thread race
conditions in security software. AES on my 3 year old desktop is >800Mbit/s
on a single core and RC4 is 2x faster again, so I don't think crypto
performance is a massive problem.

Dang! No HPN-SSH!

Posted Mar 9, 2010 22:25 UTC (Tue) by djm (subscriber, #11651) [Link]

err, s/prefer/prefer not/

Dang! No HPN-SSH!

Posted Mar 11, 2010 2:48 UTC (Thu) by martinfick (subscriber, #4455) [Link] (1 responses)

While I wouldn't want to tell you how to write secure software, I wouldn't dismiss the need for speed so quickly. Have you payed attention to CPU speed increases lately? A 3 year old desktop is far from a slow machine, especially for a single threaded app (since most CPU advances are simply adding cores). I run much older machines than that, 10+ years old, (as I suspect many using free operating systems do) and they do suffer greatly from encryption performance in local gigabit ssh file transfers. They also chew up over 50% of my CPU and all I care about is authentication and integrity from one machine in my basement to the other. Other non encrypted transfers are much faster on these machines and do not chew up my CPU.

Dang! No HPN-SSH!

Posted Mar 11, 2010 5:26 UTC (Thu) by dlang (guest, #313) [Link]

even on modern hardware the encryption overhead can limit transfer speeds.

on very modern system I can transfer data twice as fast over local gigE networks with HTTP or FTP than I can via SSH

OpenSSH 5.4 released

Posted Mar 8, 2010 17:27 UTC (Mon) by lkundrak (subscriber, #43452) [Link] (6 responses)

* Disable OOM-killing of the listening sshd on Linux. bz#1470
I'm wondering what sense does this make. Turning off a feature that would kill sshd once it goes mad and eats up all the memory and kill everything else instead? Or do they assume the oomkiller to be that stupid?

OpenSSH 5.4 released

Posted Mar 8, 2010 17:36 UTC (Mon) by ewan (guest, #5533) [Link]

Oftentimes it is that stupid, and can make a bad situation considerably worse by cutting off any hope you might have had of SSHing in and fixing the actual problem.

OpenSSH 5.4 released

Posted Mar 8, 2010 20:30 UTC (Mon) by drag (guest, #31333) [Link] (4 responses)

As far as OpenSSH is concerned, specifically, the chances of sshd flipping out and using all your
ram is much much less then having other applications flip out and use all your RAM and having
OOM kill off sshd.

For most uses of Linux killing off sshd would have a similar effect of killing up 'getty' on a local
console. OOM Killer operating in this manner is effectively like having the Linux kernel perform
it's own denial service attack on userland.

OpenSSH 5.4 released

Posted Mar 9, 2010 1:43 UTC (Tue) by BrucePerens (guest, #2510) [Link]

Remote servers without dedicated remote consoles are a lot cheaper than the other kind. Only $30 to $70 per month for a pretty good server. Of course I have them set to reboot if sshd dies, or if they can't reach their router.

OpenSSH 5.4 released

Posted Mar 9, 2010 23:26 UTC (Tue) by herodiade (guest, #52755) [Link] (2 responses)

> the chances of sshd flipping out and using all your ram is much much less

Also note protection is on the _listening_ sshd (that's not a whole lot a code ; not the user's child processes for instance).

With regard to the new certificate format, does anyone here knows why X.509 doesn't fit well for SSH?

Someone maintains a patchset to include support for X.509 certificate here http://roumenpetrov.info/openssh/ ; I can see some benefit with that from an end-user perspective (mostly, reusing existing tools for pki management, certificates revocations lists, etc).

OpenSSH 5.4 released

Posted Mar 9, 2010 23:56 UTC (Tue) by djm (subscriber, #11651) [Link] (1 responses)

I chose to avoid X.509 mostly because it is complex in encoding (ASN.1) and
semantics. Consider the number of ASN.1 related bugs that OpenSSL and other
implementations have suffered from - the fact that nobody gets this right is
a good signal that it is overly complex. Unfortunately, key/cert parsing and
validation is by necessity in the critical pre-authentication attack surface
of sshd, so bugs there are particularly nasty and could be used to write
worms.

The OpenSSH certificate format uses existing SSH signature formats and wire
encoding primitives, so all of that code is reused. Also, because these
certificates are not tied into such a heavyweight and hierarchical model of
identity, the the semantics of certificates and the workflow of creating
them is much simpler.

OpenSSH 5.4 released

Posted Mar 12, 2010 13:53 UTC (Fri) by BSchuller (guest, #64336) [Link]

Hi,

X.509 may be complex, it is widely used, and many
X.509 based infrastructures exist. Therefore, introducing a
home-grown version of X.509 requiring admins to effectively
run their own CA is hard to understand.
I think it would be a very good move if X.509 could be
supported in OpenSSH. Admins who think the security risk is
too high can always opt-out.

Best regards,
Bernd.

Tab completion in ssh

Posted Mar 9, 2010 13:50 UTC (Tue) by andikleen (guest, #39006) [Link]

The coolest new feature not mentioned is finally tab completion in ssh

But then see other comment for a serious misfeature.


Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds