LWN.net Logo

OpenSSH 6.2 released

From:  Damien Miller <djm-AT-openbsd.org>
To:  announce-AT-openbsd.org
Subject:  Announce: OpenSSH 6.2 released
Date:  Fri, 22 Mar 2013 11:40:40 +1100 (EST)
Message-ID:  <alpine.BSO.2.00.1303221139210.1392@natsu.mindrot.org>
Archive-link:  Article, Thread



Changes since OpenSSH 6.1
=========================

This release introduces a number of new features:

Features:

 * ssh(1)/sshd(8): Added support for AES-GCM authenticated encryption in
   SSH protocol 2. The new cipher is available as aes128-gcm@openssh.com
   and aes256-gcm@openssh.com. It uses an identical packet format to the
   AES-GCM mode specified in RFC 5647, but uses simpler and different
   selection rules during key exchange.

 * ssh(1)/sshd(8): Added support for encrypt-then-mac (EtM) MAC modes
   for SSH protocol 2. These modes alter the packet format and compute
   the MAC over the packet length and encrypted packet rather than over
   the plaintext data. These modes are considered more secure and are
   used by default when available.

 * ssh(1)/sshd(8): Added support for the UMAC-128 MAC as
   "umac-128@openssh.com" and "umac-128-etm@openssh.com". The latter
   being an encrypt-then-mac mode.

 * sshd(8): Added support for multiple required authentication in SSH
   protocol 2 via an AuthenticationMethods option. This option lists
   one or more comma-separated lists of authentication method names.
   Successful completion of all the methods in any list is required for
   authentication to complete. This allows, for example, requiring a
   user having to authenticate via public key or GSSAPI before they
   are offered password authentication.

 * sshd(8)/ssh-keygen(1): Added support for Key Revocation Lists
   (KRLs), a compact binary format to represent lists of revoked keys
   and certificates that take as little as one bit per certificate when
   revoking by serial number. KRLs may be generated using ssh-keygen(1)
   and are loaded into sshd(8) via the existing RevokedKeys sshd_config
   option.

 * ssh(1): IdentitiesOnly now applies to keys obtained from a
   PKCS11Provider. This allows control of which keys are offered from
   tokens using IdentityFile.

 * sshd(8): sshd_config(5)'s AllowTcpForwarding now accepts "local"
   and "remote" in addition to its previous "yes"/"no" keywords to allow
   the server to specify whether just local or remote TCP forwarding is
   enabled.

 * sshd(8): Added a sshd_config(5) option AuthorizedKeysCommand to
   support fetching authorized_keys from a command in addition to (or
   instead of) from the filesystem. The command is run under an account
   specified by an AuthorizedKeysCommandUser sshd_config(5) option.

 * sftp-server(8): Now supports a -d option to allow the starting
   directory to be something other than the user's home directory.

 * ssh-keygen(1): Now allows fingerprinting of keys hosted in PKCS#11
   tokens using "ssh-keygen -lD pkcs11_provider".

 * ssh(1): When SSH protocol 2 only is selected (the default), ssh(1)
   now immediately sends its SSH protocol banner to the server without
   waiting to receive the server's banner, saving time when connecting.

 * ssh(1): Added ~v and ~V escape sequences to raise and lower the
   logging level respectively.

 * ssh(1): Made the escape command help (~?) context sensitive so that
   only commands that will work in the current session are shown.

 * ssh-keygen(1): When deleting host lines from known_hosts using
   "ssh-keygen -R host", ssh-keygen(1) now prints details of which lines
   were removed.
    
Bugfixes:

 * ssh(1): Force a clean shutdown of ControlMaster client sessions when
   the ~. escape sequence is used. This means that ~. should now work in
   mux clients even if the server is no longer responding.

 * ssh(1): Correctly detect errors during local TCP forward setup in
   multiplexed clients. bz#2055

 * ssh-add(1): Made deleting explicit keys "ssh-add -d" symmetric with
   adding keys with respect to certificates. It now tries to delete the
   corresponding certificate and respects the -k option to allow deleting
   of the key only.

 * sftp(1): Fix a number of parsing and command-editing bugs, including
   bz#1956

 * ssh(1): When muxmaster is run with -N, ensured that it shuts down
   gracefully when a client sends it "-O stop" rather than hanging around.
   bz#1985

 * ssh-keygen(1): When screening moduli candidates, append to the file
   rather than overwriting to allow resumption. bz#1957

 * ssh(1): Record "Received disconnect" messages at ERROR rather than
   INFO priority. bz#2057.

 * ssh(1): Loudly warn if explicitly-provided private key is unreadable.
   bz#1981

Portable OpenSSH:

 * sshd(8): The Linux seccomp-filter sandbox is now supported on ARM
   platforms where the kernel supports it.

 * sshd(8): The seccomp-filter sandbox will not be enabled if the system
   headers support it at compile time, regardless of whether it can be
   enabled then. If the run-time system does not support seccomp-filter,
   sshd will fall back to the rlimit pseudo-sandbox.

 * ssh(1): Don't link in the Kerberos libraries. They aren't necessary
   on the client, just on sshd(8). bz#2072

 * Fix GSSAPI linking on Solaris, which uses a differently-named GSSAPI
   library. bz#2073

 * Fix compilation on systems with openssl-1.0.0-fips.

 * Fix a number of errors in the RPM spec files.

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

 - SHA1 (openssh-6.2.tar.gz) = XXX
 - SHA1 (openssh-6.2p1.tar.gz) = XXX

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.




(Log in to post comments)

OpenSSH 6.2 released

Posted Mar 22, 2013 16:28 UTC (Fri) by marineam (subscriber, #28387) [Link]

Oh, requiring multiple auth methods should make key+OTP workable.

OpenSSH 6.2 released

Posted Mar 22, 2013 16:36 UTC (Fri) by yokem_55 (subscriber, #10498) [Link]

The exact same thought came to my mind. Public key + Google's H/TOTP auth would be really nice to have setup. Granted, it's doubling up on the "things you have" auth mode, but this way the "things" can be on separate devices (key on system, H/TOTP app on phone).

Looking forward to playing with this.

OpenSSH 6.2 released

Posted Mar 22, 2013 16:47 UTC (Fri) by marineam (subscriber, #28387) [Link]

Yup, and each can be secured differently (phone pin, key password, etc) so in most cases that should be good enough and you get to use brain cells for remembering memes instead of passwords.

OpenSSH 6.2 released

Posted Mar 22, 2013 18:17 UTC (Fri) by aba (subscriber, #24118) [Link]

It does. I'm using the relevant patch from bugzilla for some time with exactly this scenario (ssh key + OTP).

OpenSSH 6.2 released

Posted Mar 24, 2013 10:55 UTC (Sun) by gdt (subscriber, #6284) [Link]

Just as importantly multiple methods give a simple defence against SSH door knocking.

OpenSSH 6.2 released

Posted Mar 22, 2013 17:04 UTC (Fri) by gebi (subscriber, #59940) [Link]

It would be awesome if ssh could print the ssh "key-id" of the key which authenticated for the current session.

OpenSSH 6.2 released

Posted Mar 22, 2013 18:04 UTC (Fri) by dkg (subscriber, #55359) [Link]

gebi wrote:
> It would be awesome if ssh could print the ssh "key-id" of the key which authenticated for the current session.
It does, at debug level2. So "ssh -vv remotehost" should give you some spew like:
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp :89:dd:09:d8:1a:25:8e:0e::71:f4:0c:a4:1e:fe:e0:1c
debug1: Authentication succeeded (publickey).

OpenSSH 6.2 released

Posted Mar 22, 2013 18:09 UTC (Fri) by gebi (subscriber, #59940) [Link]

Uh sorry for not being clear, i really meant "log the key-id on the server side".

Yes i does that at some debug level, though that is useless for log analysis...

OpenSSH 6.2 released

Posted Mar 22, 2013 18:55 UTC (Fri) by dkg (subscriber, #55359) [Link]

sshd logs the fingerprint of the public key when "LogLevel VERBOSE" is set in sshd_config:
Mar 22 14:51:45 remotehost sshd[14277]: Found matching RSA key: 89:dd:09:d8:1a:25:8e:0e::71:f4:0c:a4:1e:fe:e0:1c
Mar 22 14:51:45 remotehost sshd[14277]: Accepted publickey for abc123 from 127.0.0.1 port 35514 ssh2
Mar 22 14:51:45 remotehost sshd[14277]: pam_unix(sshd:session): session opened for user abc123 by (uid=0)
why is that useless for log analysis?

If there's a specific change that would make this sort of logging more useful, please make a feature request on the project's bugtracker so that we can all share in the improvement :)

OpenSSH 6.2 released

Posted Mar 23, 2013 2:21 UTC (Sat) by laptop006 (subscriber, #60779) [Link]

We had a nice patch for this at $JOB[-1], it's nice where multiple people share a single account (some sysadmins for example on systems where LDAP etc. aren't possible), ours added keyid to the "Accepted publickey" line which meant no need to do correlation.

We stopped using it in ~2009 when it was noticed that we weren't keeping up with SSH security patches.

OpenSSH 6.2 released

Posted Mar 23, 2013 14:42 UTC (Sat) by gebi (subscriber, #59940) [Link]

YES, exactly this!
Having to do correlation in logfiles is not nice!

Ideally we'd have a log line saying that ssh not only accepted a public key, but everything (including pam session setup) was successfull and after that produce a log line that the user logged in eg. with this 'public key'.

But for the beginning just adding the ssh key fingerprint in the Accepted public-key line would be fine!

OpenSSH 6.2 released

Posted Mar 23, 2013 14:56 UTC (Sat) by dkg (subscriber, #55359) [Link]

Note that one of the new features is that you can require more than one authentication/authorization mechanism to grant access. This makes "everything on one line" slightly more complex (but of course, not impossible).

I don't see the ticket at the OpenSSH bugtracker yet. If you want this improvement to happen, could you please post the suggestion there? Thanks! Suggesting improvements in the right place is a great way to contribute to free software.

OpenSSH 6.2 released

Posted Mar 23, 2013 15:07 UTC (Sat) by gebi (subscriber, #59940) [Link]

Especially the "This makes "everything on one line" slightly more complex (but of course, not impossible)." (for multi factor auth)

Yes, it makes useful log analysis much more complex for every other software, and most parsers just do it wrong.

ONE single line for either success or failure of login would be really nice. Especially pam session setup problems give strange loglines (success login, but a short connection terminated on the client).

yes, bugreport is on the way ;)

OpenSSH 6.2 released

Posted Mar 25, 2013 15:24 UTC (Mon) by niner (subscriber, #26151) [Link]

I just can't understand why people argued so much against journald which solves problems like this very neatly.

OpenSSH 6.2 released

Posted Mar 25, 2013 17:56 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

exactly how does journald solve this problem?

The problem is that the application is putting information into multiple log entries that the consumer (the log analysis tools) would really rather be in one log entry.

I don't see how any logging system can possibly solve this application problem?

OpenSSH 6.2 released

Posted Mar 25, 2013 18:26 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

It can group several messages together.

OpenSSH 6.2 released

Posted Mar 25, 2013 18:35 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

how does it know what messages it should group together?

If you are talking about having to do custom configurations to group the messages together, tools exist that can do this with syslog messages as well.

OpenSSH 6.2 released

Posted Mar 25, 2013 18:38 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Because it can group messages by process. So it makes extraction much easier, compared to the usual syslog files that can have interleaved messages.

OpenSSH 6.2 released

Posted Mar 25, 2013 18:42 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

grouping by process does not solve the problem the OP was having with the multiple messages.

It's pretty trivial to group or split syslog messages by the program name.

If you're going to say that Journald is better than syslog, you really should compare it against a modern syslog implementation (syslog-ng, rsyslog, nxlog, logstash, etc), not the historic syslog daemon. Every distro I know of except openwrt has converted over to a modern syslog daemin, and even openwrt has syslog-ng as an option.

OpenSSH 6.2 released

Posted Mar 25, 2013 10:02 UTC (Mon) by gebi (subscriber, #59940) [Link]

OpenSSH 6.2 released

Posted Apr 3, 2013 4:47 UTC (Wed) by sitaram (subscriber, #5959) [Link]

It would be even more awesome if it would add the fingerprint of the incoming public key, along with the username, when calling the external program.

I admit the use case is very narrow though; I'm speaking as the author of gitolite, where it's not uncommon to see a few hundreds or more pubkeys in one authorized_keys file. The external program could help to cut down the time taken to do the linear scan that sshd currently seems to do when presented with a key.

(And I checked the protocol; http://tools.ietf.org/html/rfc4252#section-7 appears to indicate that some information about the key being offered (it's called "public key blob" in the rfc) *does* go to the ssh server from the ssh client before any authN happens.

OpenSSH 6.2 released - thoughts for larger systems

Posted Mar 22, 2013 21:57 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

Prior to this official OpenSSH does a great job for small systems, but it does get troublesome to manage it securely as a system grows, as the number of people using it grows, or both together. You either resort to password authentication (because you can centrally manage that) and lose the benefit of public key auth, or you end up maintaining some Heath Robinson scripts to update authorized_keys files everywhere and either way you can't really do multi-factor cleanly. As OpenSSH 6.2 (or backports of these now official patches) lands in more places that problem goes away.

AuthorizedKeysCommand plus AuthenticationMethods offers a future where redundant, SSL-secured LDAP servers maintain the public key list and password hashes for all your users, and you need both to log in. So you have multi-factor, plus you get to enforce password policy (length of password, frequency of change) and you get to easily administrate all this centrally.

And if you want to make your life _really_ easy, get DNSSEC (at least within your own networks) and use the support for DNS-based host key verification, which eliminates the need to maintain known_hosts files or (the reality in too many systems) do blind trust on first usage.

OpenSSH 6.2 released - thoughts for larger systems

Posted Mar 23, 2013 4:33 UTC (Sat) by pabs (subscriber, #43278) [Link]

Another approach for your last paragraph is to use the OpenPGP web of trust, then you aren't relying on any central authority for your security. The Monkeysphere Project maps the OpenPGP web of trust onto SSH (and the web):

http://web.monkeysphere.info/

OpenSSH 6.2 released

Posted Mar 23, 2013 2:22 UTC (Sat) by laptop006 (subscriber, #60779) [Link]

" * ssh(1): Added ~v and ~V escape sequences to raise and lower the
logging level respectively.

* ssh(1): Made the escape command help (~?) context sensitive so that
only commands that will work in the current session are shown."

Thanks for these, both will be really handy, SSH's escape sequences are something more people really should know about.

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