We have written many articles in the past about SSH hardening.
Today, we are going to explain another SSH hardening tips, how to disconnect automatically inactive ssh sessions after five minute inactivity.
You feel sleepy because you have been working for a long time in the ssh session. So you need a cup of coffee to avoid sleep.
If you are already tired, you will forget to lock your system.
This is a very important issue because you forget to lock your computer when you leave your desk so anyone can access your session and do whatever they want.
If someone has made some changes, it is very difficult to find. But eventually you have to suffer and face the consequences.
The following articles may help you to learn more about SSH related stuff.
- SSH Related Articles
- Mosh (Mobile Shell) – Best Alternative for SSH to Connect Remote System
- How to Access Secure Shell (SSH) Servers Through Standard Web Browsers
- rtop – A Nifty Tool to Monitor Remote Server Over SSH
- How to Kill or Terminate an Inactive or Idle SSH Session on Linux
- How to Execute Commands on Remote Linux System over SSH
To deal with this kind of situation, I advise you to follow the procedure below to automatically disconnect an inactive ssh session after five minutes of inactivity.
It saves you in many ways, directly or indirectly.
How to Configure SSH Service to Automatically Disconnect After a Few Minutes of Inactivity
It’s very simple and straightforward.
To do so, open the /etc/ssh/sshd_config
file on the system and change the settings below to disconnect the idle SSH sessions after a few minutes of inactivity.
If you want to disconnect the SSH session after five minutes of inactivity, just uncomment the parameters below and add the values described below.
# vi /etc/ssh/sshd_config ClientAliveInterval 300 ClientAliveCountMax 0
Once you have made changes, restart the ssh service to take the changes to effect. This modification will disconnect the user ssh sessions after inactivity of five minutes.
Run the following systemd command or SysVinit command to start the ssh service.
Use the following command to start a ssh service on RHEL-based SysVinit systems such as CentOS and Fedora.
# service sshd start or # /etc/init.d/sshd start
To start the ssh service on RHEL-based systemd systems such as CentOS and Fedora, use the following command.
# systemctl start sshd.service or # systemctl start sshd
To start the ssh service on Debian-based systemd systems such as Ubuntu and LinuxMint, use the following command.
# systemctl start ssh.service or # systemctl start ssh
How Can You Check if This Test Works or not?
Everything is done and you finally have to check by logging into two different sessions to see if this configuration works fine or not.
Now, we’re going to log in as the mageshm
and root
user, and “mageshm” leave the user session idle and check the session status from the root session (every minute) to see what happens.
See the below output for better understanding.
According to the output below, the ideal time for mageshm user 1:06
.
# w
12:22:04 up 8 days, 22:16, 2 users, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/0 219.91.219.14 11:48 0.00s 0.10s 0.00s w
mageshm pts/1 219.91.219.14 12:20 1:06 0.01s 0.01s -bash
According to the output below, the ideal time for mageshm user 2:07
.
# w
12:23:05 up 8 days, 22:17, 2 users, load average: 0.05, 0.01, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/0 219.91.219.14 11:48 0.00s 0.10s 0.00s w
mageshm pts/1 219.91.219.14 12:20 2:07 0.01s 0.01s -bash
According to the output below, the ideal time for mageshm user 3:15
.
# w
12:24:13 up 8 days, 22:18, 2 users, load average: 0.01, 0.01, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/0 219.91.219.14 11:48 0.00s 0.10s 0.00s w
mageshm pts/1 219.91.219.14 12:20 3:15 0.01s 0.01s -bash
According to the output below, the ideal time for mageshm user 4:31
.
# w
12:25:29 up 8 days, 22:20, 2 users, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/0 219.91.219.14 11:48 0.00s 0.12s 0.02s w
mageshm pts/1 219.91.219.14 12:20 4:31 0.01s 0.01s -bash
According to the output below, the ideal time for mageshm user 4:59
.
# w
12:25:57 up 8 days, 22:20, 2 users, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/0 219.91.219.14 11:48 0.00s 0.12s 0.00s w
mageshm pts/1 219.91.219.14 12:20 4:59 0.01s 0.01s -bash
According to the below output, the “mageshm” user session was automatically disconnected after five minutes of inactivity, because I could see only one session belonging to the root user. Yes, this implementation works as expected.
# w 12:26:00 up 8 days, 22:20, 1 user, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/0 219.91.219.14 11:48 0.00s 0.12s 0.00s w
At the same time the following error occurred while I was checking out the “mageshm” Putty session.
PuTTY Fatal ErrorX
Server unexpectedly closed network connection
How Does Work?
You can do this by enabling the “ClientAliveCountMax” and “ClientAliveInterval” options in the “sshd_config” file.
ClientAliveCountMax:
This represents the total number of client alive messages sent by the ssh client without receiving any response from the ssh client.
By default ClientAliveCountMax 3 and we set it to zero (0) to verify this test. If this threshold is reached when server alive messages are sent, the ssh will be disconnected from the server and the session terminated.
ClientAliveInterval
This means expiration in X seconds, in my case it is (300 seconds). After 5 minutes, sshd will send a message via an encrypted channel to request a response from the client.
The default is 0, which indicates that these messages are not sent to the client.
It works, but can be overridden by the client by using the ServerAliveInterval option less than the timeout value