LWN: Comments on "OpenSSH 6.2 released"

OpenSSH 6.2 released

sitaram — 2013-04-03T04:47:55+00:00

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

dlang — 2013-03-25T18:42:18+00:00

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

Cyberax — 2013-03-25T18:38:11+00:00

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

dlang — 2013-03-25T18:35:53+00:00

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

Cyberax — 2013-03-25T18:26:11+00:00

It can group several messages together.

OpenSSH 6.2 released

dlang — 2013-03-25T17:56:12+00:00

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

niner — 2013-03-25T15:24:03+00:00

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

OpenSSH 6.2 released

gebi — 2013-03-25T10:02:22+00:00

https://bugzilla.mindrot.org/show_bug.cgi?id=2082

OpenSSH 6.2 released

gdt — 2013-03-24T10:55:16+00:00

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

OpenSSH 6.2 released

gebi — 2013-03-23T15:07:27+00:00

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

dkg — 2013-03-23T14:56:45+00:00

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

gebi — 2013-03-23T14:42:30+00:00

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 - thoughts for larger systems

pabs — 2013-03-23T04:33:31+00:00

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

laptop006 — 2013-03-23T02:22:42+00:00

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

OpenSSH 6.2 released

laptop006 — 2013-03-23T02:21:31+00:00

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 - thoughts for larger systems

tialaramex — 2013-03-22T21:57:11+00:00

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

dkg — 2013-03-22T18:55:35+00:00

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

aba — 2013-03-22T18:17:56+00:00

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

OpenSSH 6.2 released

gebi — 2013-03-22T18:09:32+00:00

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

dkg — 2013-03-22T18:04:51+00:00

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

gebi — 2013-03-22T17:04:17+00:00

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

marineam — 2013-03-22T16:47:59+00:00

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

yokem_55 — 2013-03-22T16:36:52+00:00

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

marineam — 2013-03-22T16:28:33+00:00

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