How can I log SSH access attempts and keep track of what SSH users end up doing on my server?

Question

I've had a few security problems with a server of mine because a few SSH users have been causing problems.

So I would like to:

• Track user logins and logouts
• Track activity of these SSH users, in order to discover any malicious activity
• Prevent users from deleting logs

Solution 1

The ssh daemon, sshd, has much of this built in and enabled. Here's are some sample lines from /var/log/secure on my machine (names and IP addresses changed):

Sep  7 08:34:25 myhost sshd[6127]: Failed password for illegal user root from 62.75.999.999 port 52663 ssh2
Sep  7 08:34:26 myhost sshd[7253]: User root not allowed because listed in DenyUsers
Sep  7 08:34:28 myhost sshd[7253]: Failed password for illegal user root from 62.75.999.999 port 53393 ssh2
Sep  7 11:55:18 myhost sshd[11672]: Accepted password for gooduser from 98.999.26.41 port 43104 ssh2
Sep  7 23:01:28 myhost sshd[22438]: Did not receive identification string from 999.56.32.999
Sep  8 06:31:30 myhost sshd[21814]: Accepted password for gooduser from 98.999.26.41 port 5978 ssh2

This example shows a couple attempts by somebody to ssh into this machine as root -- both were denied because root is forbidden. It also shows a successful login by the user named "gooduser".

To fine tune what you see and in which file, read more in the sshd_config man page -- specifically the options for LogLevel and SyslogFacility.

Solution 2

Following up on what Doug Harris answered (and only addressing part of your question - this seems to be how I work), the Logwatch package will email you a daily summary of a number of server logs, including the SSHd log. I get a summary of who successfully logged in via SSH, how many times, and from where, as well as what IPs tried to log in unsuccessfully and what credentials they used. It gets long if someone tries a brute-force SSH attack on a host where I'm allowing password authentication (I try to avoid that, favoring RSA keys instead, but the customer is always right and doesn't always understand public-key authentication. Anyway.)

To install Logwatch (which is basically just a collection of Perl filters for digesting various log formats) on Ubuntu, use apt-get install logwatch and then edit /etc/cron.daily/00logwatch, replacing --output mail with --mailto [email protected]. You'll get one a day. You can add more flags to tune which logs Logwatch actually reads.

Solution 3

One a very complete way of tracking users is to use auditd. It's a kernel level way to track whatever you need to audit. It should be bundled with Ubuntu Server and if not already running, should be startable with sudo service auditd start.

There are plenty of configuration examples for it under /usr/share/doc/auditd/ or something similar to that, and of course if you Google for auditd tutorial, you'll be rewarded with many, many tutorials.

The reports generated by auditd are stored in /var/log/audit/ directory. They also can be parsed to more human-readable form with tools like aureport and ausearch, also should already be bundled with Ubuntu Server.

Solution 4

I wouldn't give out ssh-accounts, especially to distro-groups type people.

Here's a couple of things:

• last, gives you a history of recent login-out's.
• Harden the bash history to prevent wiping out the command history http://sock-raw.org/papers/bash_history

From Can history files be unified in bash?

Insert the command shopt -s histappend in your .bashrc. 
This will append to the history file instead of overwriting it.
Also in your .bashrc, insert

PROMPT_COMMAND="$PROMPT_COMMAND;history -a; history -n"

and the history file will be re-written and re-read each time
bash shows the prompt.

View more solutions

Comments

[subanki]

I think this question belongs in serverfault.com (but i am not sure )

[mc0e]

The OP specified Ubuntu, so by default this info would be in /var/log/auth.log - RHEL, Centos, et al use /var/log/secure by default. In either case that comes down to not only the configuration of SyslogFacility in the sshd configuration, but also the configuration of the syslog daemon - e.g. in /etc/rsyslog.conf. Perhaps you might be arranging log files differently in local files, or you might be shipping your logs to somewhere else entirely.