Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
OpenSSH 6.2 released
Posted Mar 22, 2013 18:04 UTC (Fri) by dkg (subscriber, #55359)
> It would be awesome if ssh could print the ssh "key-id" of the key which authenticated for the current session.
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).
Posted Mar 22, 2013 18:09 UTC (Fri) by gebi (subscriber, #59940)
Yes i does that at some debug level, though that is useless for log analysis...
Posted Mar 22, 2013 18:55 UTC (Fri) by dkg (subscriber, #55359)
Mar 22 14:51:45 remotehost sshd: 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: Accepted publickey for abc123 from 127.0.0.1 port 35514 ssh2
Mar 22 14:51:45 remotehost sshd: pam_unix(sshd:session): session opened for user abc123 by (uid=0)
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 :)
Posted Mar 23, 2013 2:21 UTC (Sat) by laptop006 (subscriber, #60779)
We stopped using it in ~2009 when it was noticed that we weren't keeping up with SSH security patches.
Posted Mar 23, 2013 14:42 UTC (Sat) by gebi (subscriber, #59940)
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!
Posted Mar 23, 2013 14:56 UTC (Sat) by dkg (subscriber, #55359)
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.
Posted Mar 23, 2013 15:07 UTC (Sat) by gebi (subscriber, #59940)
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 ;)
Posted Mar 25, 2013 15:24 UTC (Mon) by niner (subscriber, #26151)
Posted Mar 25, 2013 17:56 UTC (Mon) by dlang (✭ supporter ✭, #313)
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?
Posted Mar 25, 2013 18:26 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
Posted Mar 25, 2013 18:35 UTC (Mon) by dlang (✭ supporter ✭, #313)
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.
Posted Mar 25, 2013 18:38 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
Posted Mar 25, 2013 18:42 UTC (Mon) by dlang (✭ supporter ✭, #313)
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.
Posted Mar 25, 2013 10:02 UTC (Mon) by gebi (subscriber, #59940)
Posted Apr 3, 2013 4:47 UTC (Wed) by sitaram (subscriber, #5959)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds