I've had a few security problems with a server of mine, a few SSH users have been setting up fires aka giving problems.

I would like to:

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

I am not much of a sys admin and I am quite inexperienced in this matter, so any kind of advice would be very welcome and very helpful. :)

5 Answers 5


Since we're talking about SSH servers, I will give you command line solutions.

  • Track user logins and logouts. That's easy, the file /var/log/auth.log should have this information.

  • Track activity of those users: If they are fairly innocent, you can check the file .bash_history in their home dir. You will see a list of the commands that they executed. The problem is of course that they can delete or edit this file.

  • Prevent users from deleting logs: Users shouldn't be able to touch auth.log. In order to stop them from playing with .bash_history you need to do a couple of tricks.

  • What if the user manages to obtain root access? : You're screwed. Unless they make a mistake they will be able to hide all their footsteps.

  • Note that there is no way to prevent users from typing unset HISTFILE inside bash, and then their bash history won't be recorded. Commented Sep 9, 2010 at 21:21
  • @Gilles, please read the tricks link. They set HITSFILE as a readonly variable in .profile. Commented Sep 10, 2010 at 7:15
  • I thought you could unset a readonly variable in a non-restricted bash, but apparently not. This improves traceability a little since starting another shell (which won't read ~/.bash_history or ~/.bashrc) will show up in $HISTFILE. But that in itself could be perfectly legitimate (e.g. the user just wants to run zsh, or wants to set their own option in an alternate bashrc). Commented Sep 10, 2010 at 7:31
  • 1
    Yes. You can restrict him to bash or some other shell. After all security is just a race. Commented Sep 10, 2010 at 9:19
  • 1
    It's not true that "if user manages to obtain root access" they would be able to hide all steps. You can always use external server for audit, where all the steps would be recorded, including their becoming of root.
    – Petr
    Commented Jun 16, 2016 at 10:37

[DISCLAIMER] I realize I am late to the party, but I would like to paste an answer that I gave to another question, because I feel like it can offer some good insight to readers, and this question seems to be the go-to place for basic ssh info.

There was a similar problem that struck me after reading this question here on AskUbuntu and checking my VPS, only to see a bazillion of brute force attempts. That is when I decided to take action.

Now according to the question I linked to, if you would like to see failed login attempts on your machine over ssh (could be brute force attempts or anything), try typing this:

grep sshd.\*Failed /var/log/auth.log | less

If the output consists of multiple lines, that is many brute force attempts, especially if they have happened between short intervals, you might want to do the following pieces of action:

Change the ssh configuration file

To do this, open the file located at /etc/ssh/sshd_config with your favourite editor, like this vim /etc/ssh/sshd_config.

1. Try to move ssh from port 22: Now locate the line that reads:

# What ports, IPs and protocols we listen for
Port 22

and comment out Port 22, and use anyone you might like. Example:

# What ports, IPs and protocols we listen for
# Port 22
Port 28934

Please remember that ports below 1024 need special (root) permission. I do not know how this could interfere with it, but I am just saying.

2. Disable Root logins via ssh: Since the root username is predictable and provides complete access to your system, providing unfettered access to this account over SSH is unwise. Locate the line reading PermitRootLogin and set it to no.

PermitRootLogin no

3. Disable password authentication: Generate and use SSH keys to log into your system. Without passwords enabled, attackers will need to guess (or steal) your SSH private key in order to gain access to your server. Something that is very very difficult. Proceed to find the line that reads PasswordAuthentication and set it to no

PasswordAuthentication no

!WARNING! Before doing so, please consult this guide over here on how to set up certificate authentication.

NOTE: After you have made the changes use sudo /etc/init.d/ssh restart. To connect to another port via ssh use: ssh [email protected] -p <port_number>.

Setup a firewall

Please check out this guide on how to set up the extremely powerful and effective firewall, which is integrated into Linux, IPTables.

Setup scripts to help you with security

One that I use personally and quickly comes to mind is Fail2Ban. Fail2ban will monitor your log files for failed login attempts. After an IP address has exceeded the maximum number of authentication attempts, it will be blocked at the network level and the event will be logged in /var/log/fail2ban.log. To install it: sudo apt-get install fail2ban

Check command history via ssh

There is a linux command, named history, which allows you to see which commands have been input up until that point. Try typing history in a terminal to get to see all commands up to that point. It could help if you were root.

To search for a particular command try: history | grep command-name

To list all commands after ssh: fc -l ssh

You can also edit commands using vi (haven't tried it vim, though I assume it works as well): fc -e vi

You can also delete the history: history -c

NOTE: If you are not a fan of the command history there is also a file in your home directory (cd ~), called .bash_history (if you are using bash) that you can cat to see all that has been typed in the bash shell.


A bit overkill, but you can see everything that is run on your system using the "process event connector":


  1. Javier already answered this one: /var/log/auth.log
  2. I have found a great article about this here.
  3. If your users don't have access to root then your log files should be safe. You can try to build some custom rules in the sudoers file to restrict what your users can access and how. Also you can increase the log level for the sshd daemon.

Apart from the login itself there is no safe way to track/log users actions after they log in, assuming they have basic Linux knowledge they will be able to disable shell logging or simply running commands from other shells (e.g. python).

Instead you should be conservative about providing ssh access, do they really need it ? It's not very common to grant ssh access unless you are on the shell providing business.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .