How to audit Secure Shell (ssh) logins

[Lolupee]

Reference to above subject and
DocId: KBRC00016329.

Do we now have capability of auding ssh logins.

[Rick Garland]

I have modified the /etc/syslog.conf file to capture and store ssh login info. Also includes failed attempts to login via ssh.

auth.debug /var/adm/syslog/ssh.log

This is the entry in the syslog.conf file.
Stop and restart the syslogd process.

A new log file, ssh.log, will be created and appended to.

[Lolupee]

Thanks, but HP has not added ssh to its audit events or syscol correct?

[DCE]

We are using the ssh and trusted systems.

I can find info on ssh connections using last -R, and/or by grepping for login (or FAILED) on the syslog.

You can also turn on auditing - but make sure you hav adequate disk space if you choose this option

[Doug O'Leary]

Hey;

This is one of my pet peeves about openssh. The ssh protocol is an absolutely incredible boon to secure system administration - particularly when you get into the public key authentication.

Fsecure, a commercial ssh ver2 implementation will log via syslog which key was logged in for which user. Meaning if I set up oracle to accept my key, and I execute:

ssh -l oracle ${host}

fsecure would syslog the fact that it let me in using my public key.

openssh won't do that.

I just tried the auth.debug thing and it gives you some information; however, not what I've been looking for. To wit:

Dec 5 15:31:12 usilap17 sshd[24424]: perform_passwd_aging_check: 13117 13122 -1 -1
Dec 5 15:31:12 usilap17 sshd[24424]: Accepted publickey for ${user} from 111.222.333.4444 port 32922 ssh2

The accepted publickey is already in the syslog using normal logging.

The only work around to this that I know about is to set the the debug level on the ssh daemon. This will get you the information; however, dumps *so* much information to the syslog that it's practically worthless.

So, now that I'm off my soapbox, the short answer to your question is no, nothing that doesn't show up in the syslog already - at least nothing that will support nonrepudiation...

Doug

[Jeff Schussele]

I agree with Doug.
Getting "useful" login info other than source IP results in "volumes" of info you don't need/want.
My *other* problem with OpenSSH is that when keys are used the "standard" PAM modules are bypassed altogether which means that PW expiration msgs & "forced" PW change requests are not even generated.
As long as the key is good - you get in.
We are finding this quite troubling in the LDAP / Trusted world.
HP needs to do something about their PAM modules & *how* they interact with SSH and LDAP especially in Trusted envs.

My $0.02,
Jeff

[TEC-HP]

Agree with Jeff:
better integration ssh-pam-kerberos needed
See also
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=964371
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=980805

for "command-auditting" see
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=805145

[Lolupee]

Thanks all, I got what I need. HP still has work to do.

[Robert Fritz]

Regarding the logging part of this thread: Pardon if I missed something, but on my 11.11 system, I seem to be getting plenty of failure/success logs from sshd in syslog. I see pubkey and passwd entries.

This is using standard out-of-the box configuration, using the free HP-built ssh.

What's missing? Did you want the actual key fingerprint in the logs, or is the concern that the non-supported openssh build does something different than below?

I've included some reference output that seems to have what you'd want:

Dec 6 10:26:17 nina sshd[24259]: error: PAM: Authentication failed for root from gold.fc.hp.com
Dec 6 10:27:01 nina sshd[24259]: Failed keyboard-interactive/pam for root from 15.1.49.20 port 49547 ssh2
Dec 6 10:27:03 nina sshd[24259]: Failed password for root from 15.1.49.20 port 49547 ssh2
Dec 6 10:27:01 nina sshd[24259]: error: PAM: Authentication failed for root from gold.fc.hp.com
Dec 6 10:27:08 nina sshd[24259]: Accepted password for root from 15.1.49.20 port 49547 ssh2
Dec 6 10:27:04 nina sshd[24259]: Failed password for root from 15.1.49.20 port 49547 ssh2
Dec 6 10:27:34 nina sshd[24316]: Accepted publickey for root from 15.1.51.143 port 16295 ssh2
Dec 6 10:59:47 nina sshd[24759]: Accepted publickey for fritzr from 15.238.14.195 port 2809 ssh2

[Doug O'Leary]

>> Dec 6 10:27:08 nina sshd[24259]: Accepted password for root from 15.1.49.20 port 49547 ssh2

Who logged in as root? A password will never be able to tell you that. That's why the best way to allow direct root login is via PKA

"PermitRootLogin without-password" in the /opt/ssh/etc/sshd_config

>> Dec 6 10:27:34 nina sshd[24316]: Accepted publickey for root from 15.1.51.143 port 16295 ssh2

Who's key was used? The concept on nonrepudiation in security means that the person that logged in can't say "That wasn't me!" Since you don't know who's key was used, you're no better off than with password authentication.

If the syslog entry said "Accepted fritz's public key for root from 15.1.51.143" then you know who logged in and from where.

The key's fingerprint would be a start - at least you could figure out who's key was used from that point...

Doug

[Robert Fritz]

Thanks Doug,

I can pass on the feedback re: kerberos/SSH interaction, in reference to shared-accounts.

A couple logging-facilitation possibilities with today's capabilities (for free vs. the fsecure option you'd mentioned):

1) For accounts that you can't avoid sharing, consider multiple accounts with the same uid.
2) Consider tools like sudo, su, or HP-UX RBAC (or arguably SIM) to minimize the need for management-account sharing.

Hope that helps,
-R

[Lolupee]

Thanks to all