Many people don't run the SSH that comes with Solaris 9 and later on their Solaris hosts, instead opting for OpenSSH or one of Tectia's SSH products. Some don't like SunSSH's versioning, as it makes it hard to determine if SunSSH is vulnerable to the same issues as OpenSSH (most often it's not or the issue has already been addressed), others rely on features on OpenSSH that haven't made it into SunSSH (there aren't many) and then there are those who's corporate guidelines only allow for a third party solution - probably for uniformity across platforms. Whatever the reason, all of these people are security conscious so they may also have an auditing (aka BSM) requirement too, and this is where the problem comes to light: they soon discover that it appears that not all events are being recorded for users who connect via this third party SSH software.
Thankfully it's easy to get OpenSSH working with Solaris auditing thanks to the very generous code contributions made by Sun to the OpenSSH community, way back in 2001, that were finally included in OpenSSH 4.0 and later. However, despite these contributions, people still miss the details on getting BSM working as they expect and this is what I'll address here.
When a sysadmin has been told he needs to install OpenSSH and enable auditing on their Solaris hosts, the process normally goes as follows:
loto the flags line in
/etc/security/audit_control, enable auditing by running
/etc/security/bsmconvand then reboot.
$ ssh email@example.com firstname.lastname@example.org's password: Last login: Wed Jun 16 13:38:45 2010 Sun Microsystems Inc. SunOS 5.10 Generic January 2005 # auditreduce -c lo | praudit -s Warning: invalid event no 32800 in audit trail.file,1970-01-01 01:00:00.000 +01:00, file,2010-06-16 16:49:30.000 +01:00, #
Huh?? No login record.
More often than not, most admins then pick up the phone and call
Sun Oracle asking for some help only to be told "Sorry, we don't support OpenSSH. Try with Sun's SSH and get back to us if you still have a problem. Oh yes, and don't forget to read the configuration documentation".
Sun Oracle gave is actually the clue here. As most sysadmins don't compile OpenSSH from source (who could blame them), they miss out on the opportunity to read the
README.platform file supplied with OpenSSH (it's installed in
/usr/local/doc/openssh/README.platform when you install the Sunfreeware SMCosh551 pkg) and this Solaris specific snippet:
Solaris ------- If you enable BSM auditing on Solaris, you need to update audit_event(4) for praudit(1m) to give sensible output. The following line needs to be added to /etc/security/audit_event: 32800:AUE_openssh:OpenSSH login:lo The BSM audit event range available for third party TCB applications is 32768 - 65535. Event number 32800 has been choosen for AUE_openssh. There is no official registry of 3rd party event numbers, so if this number is already in use on your system, you may change it at build time by configure'ing --with-cflags=-DAUE_openssh=32801 then rebuilding.
Scroll back up and take another look at the auditreduce output I've included above. Now you know what is causing that warning and how to resolve it. Adding the entry above to the
/etc/security/audit_event and re-loading auditing (or rebooting) will clear the message and now show your OpenSSH logins:
# auditreduce -c lo | praudit -s file,2010-06-16 16:49:19.000 +01:00, header,94,2,AUE_openssh,,s10vb,2010-06-16 16:49:19.278 +01:00 subject,root,root,root,root,root,932,932,0 51558 192.168.0.2 text,successful login root return,success,0 header,89,2,AUE_logout,,s10vb,2010-06-16 16:52:15.698 +01:00 subject,root,root,root,root,root,932,932,0 51558 192.168.0.2 text,sshd logout root return,success,0 header,94,2,AUE_openssh,,s10vb,2010-06-16 16:52:19.578 +01:00 subject,root,root,root,root,root,953,953,0 51569 192.168.0.2 text,successful login root return,success,0 file,2010-06-16 16:52:19.000 +01:00, #
And there we have it. Auditing working with OpenSSH. In fact, truth be told, auditing was always working here. Had the admin enabled other events to audit or logged out and then in again before checking the audit records, they would have seen an audit record for those events along with the warning.
If you happen to get output similar to:
# auditreduce -c lo | praudit -s file,1970-01-01 01:00:00.000 +01:00, file,2010-06-16 16:58:49.000 +01:00, #
... it means either your SSH implementation hasn't been compiled with auditing/BSM support, you've not enabled auditing or you've not configured it correctly so it's time to hit the documentation and test using a Sun supplied login mechanism. Don't forget that processes need to be restarted in order for them to be picked up by your auditing changes, so if in doubt, reboot.
On a side note, you may want to seriously consider using the SSH implementation that comes with the OS. Not only is it supported by the same people who provide you with the OS, it also has some features OpenSSH doesn't, most notably hardware acceleration by default. See the SunSSH community page for more details on Sun's implementation.