Hi, I admin a box that has Subversion users authenticate with public keys to a restricted 'svnuser' account. The comment field of all the keys describe who they belong to (it has their usernames), but unfortunately, sshd does not log this when a user successfully authenticates: Jun 21 08:18:22 localhost sshd[23636]: Accepted publickey for svnuser from x.x.x.x port 2065 ssh2 Jun 21 08:18:24 localhost sshd[23668]: Accepted publickey for svnuser from y.y.y.y port 2067 ssh2 The above two logins were for two distinct keys with distinct comment fields. However, as you can see, the logs they generate are indistinguishable; I can't easily tell what two users these are. I've tested this against OpenSSH v5.0 with LogLevel set to VERBOSE. Am I correct in that sshd does not support logging of the key's comment field? If so, then I volunteer to implement the feature. Just let me know and I'll get started. I'm looking forward to doing some development work. Thanks! - Joe -- Joseph S. Testa II | Senior Security Consultant Positron Security, LLC. http://www.positronsecurity.com Phone: (585) 643-5900 AIM / Skype: TheRealJoeTesta
On Sun, Jun 22, 2008 at 9:42 PM, Joe Testa <jtesta at positronsecurity.com> wrote:> I admin a box that has Subversion users authenticate with public keys > to a restricted 'svnuser' account. The comment field of all the keys > describe who they belong to (it has their usernames), but unfortunately, > sshd does not log this when a user successfully authenticates: > > Jun 21 08:18:22 localhost sshd[23636]: Accepted publickey for svnuser > from x.x.x.x port 2065 ssh2 > Jun 21 08:18:24 localhost sshd[23668]: Accepted publickey for svnuser > from y.y.y.y port 2067 ssh2 > > The above two logins were for two distinct keys with distinct comment > fields. However, as you can see, the logs they generate are > indistinguishable; I can't easily tell what two users these are. I've > tested this against OpenSSH v5.0 with LogLevel set to VERBOSE. > > Am I correct in that sshd does not support logging of the key's > comment field?It doesn't support logging the comment field, but it does support logging the key fingerprint, which uniquely identifies the key (which the comment doesn't) but it's logged at level DEBUG1 not VERBOSE. (See, eg auth2-pubkey.c and look for "Found matching"). Also, from memory the message is logged by the privsep slave, so in order for it to work you need a /dev/log inside the privsep chroot for it to work. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
> It doesn't support logging the comment field, but it does support > logging the key fingerprint, which uniquely identifies the key (which > the comment doesn't) but it's logged at level DEBUG1 not VERBOSE. > (See, eg auth2-pubkey.c and look for "Found matching").Yep, I've seen it do this while playing around. Even if an admin does enable that level of logging, its pretty hard to memorize the key fingerprints and their owners, especially for large/dynamic environments. I understand that the key comment is not necessarily unique, but in my situation I've made them unique for the purposes of management (so it is clear which key belongs to whom when I need to revoke access), and so logging the comment would restore meaning to log entry. I think it is plausible that there are many installations that do tunneling for Subversion and/or database services over a single system account to warrant this feature. What do you think? (I wasn't sure from your response if you were receptive to my idea. I'd like to know for sure if it has a chance of getting checked into the tree before I start working on it.) Thanks! - Joe -- Joseph S. Testa II | Senior Security Consultant Positron Security, LLC. http://www.positronsecurity.com Phone: (585) 643-5900 AIM / Skype: TheRealJoeTesta
Maybe Matching Threads
- CISA et al: "Exploring Memory Safety in Critical Open Source Projects"
- An Analysis of the DHEat DoS Against SSH in Cloud Environments
- DH Group Exchange Fallback
- Log ssh sessions using open source tools
- An Analysis of the DHEat DoS Against SSH in Cloud Environments