How to Automatically Disconnect Idle or Inactive SSH Sessions After Five Minutes of Inactivity

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.

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              [email protected]   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              [email protected]   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              [email protected]   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              [email protected]   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              [email protected]   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              [email protected]   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 Error

X

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.

Magesh Maruthamuthu

Love to play with all Linux distribution

You may also like...