Why are my log in times taking so long in Linux?
In recent weeks, login times on my Ubuntu server have started timing out; both through SSH and the local command line console. Examination of the /var/log/auth.log files yields nothing interesting. How can I diagnose long log in times on my Ubuntu server? I should mention, also, that no updates have been performed since the problem has started, and that the / , /boot/ and /usr/ file systems are mounted as readonly. [Edit] This is a stand alone machine, so it doesn’t authenticate with Active Directory, LDAP etc. Also, the login prompt is responsive, as is the password prompt. Upon typing the password then CR, I’ll timeout. After four a five tries, I will be able to login, although I’m worried this will start taking longer.
Where are your user accounts stored? Locally in /etc/passwd ? LDAP? Kerberos? Active Directory? NIS/YP?
@sysadmin1138: Not a GUI, I thought I was clear about it being SSH and a console, I added «command line» in front of console.
ssh -vvv Adding the verbose flag to SSH commands usually helps me troubleshoot issues with login that is not immediately apparent. The first thing that you must figure out is if it is an issue with network connection (interruption // dropped packets // firewalls) or with the configuration of the machine itself. This thread is likely to go unsolved since so much time has passed, but hopefully this helps someone else coming back to this.
6 Answers 6
Quite often this is due to a reverse DNS lookup of your host IP.
Make sure your client IP has a reverse IP DNS record.
See this link for more details of a work around if setting up reverse records is out of your sphere of influence.
I’m not too keen on trying this for two reasons: only recent this has come about, and the sshd_config file has been static for months, and secondly, this also happens when I’m logging in on the local console (no ssh).
Agreed that it’s odd that local logins would lag, but it’s trivial to check if your DNS is working and/or if your clients have reverse DNS configured. Try that?
Take a look at the UseDNS [yes|no] in the sshd_config file. If it is set to Yes there is a good chance that a delay will/can occur. Take a look here: OpenSSH FAQ especially chapter 3.3. It also points to some other possible delay causes.
This thread is old but I felt onto it seeking for answers. I give my solution here. My problem (took about 1 minutes to ssh login into my raspberry pi), was due to a corrupted .bash_history file. Since the file is read at login, this was causing the login delay. Once I removed the file, login time went back to normal, like instantaneous.
Hope this will help some other people.
Perhaps your /bin/login has been replaced by an evil twin that ships your passwords offsite. If such a program is poorly written, it could be hanging and/or timing out.
Perhaps your user’s (or system-wide) shell profile/rc is running something slow
Are logins also slow in single user (runlevel 1) mode? Are you in runlevel 5? if so, try going to runlevel 3 (if you can) and see if there’s a change in login speed.
/bin/login/ : The system was connected to the network after the important partitions were made read only. I checked just in case.
Do you have nscd running ( pidof nscd )? If so, shut it down and see if it gets better. If it does get better, do rm /var/db/nscd/* and start it back up.
Most of the answers on SO and elsewhere suggested the problem was a DNS issue. On a Debian system with a very long uptime, I saw it stalled out on talking to a dbus socket (logs shown below). Turns out, restarting dbus systemctl restart dbus fixed the problem
15:50:20.475652 connect(4, , 30) = 0 15:50:20.475823 getsockopt(4, SOL_SOCKET, SO_PEERCRED, , [12]) = 0 15:50:20.475981 getsockopt(4, SOL_SOCKET, SO_PEERSEC, 0x7f301f9a1340, [64]) = -1 ENOPROTOOPT (Protocol not available) 15:50:20.476135 getsockopt(4, SOL_SOCKET, SO_PEERGROUPS, 0x7f301f9af260, [256]) = -1 ENOPROTOOPT (Protocol not available) 15:50:20.476285 fstat(4, ) = 0 15:50:20.476430 getsockopt(4, SOL_SOCKET, SO_ACCEPTCONN, [0], [4]) = 0 15:50:20.476584 getsockname(4, , [128->2]) = 0 15:50:20.476735 geteuid() = 0 15:50:20.476868 sendmsg(4, , , ], msg_iovlen=3, msg_controllen=0, msg_flags=0>, MSG_DONTWAIT|MSG_NOSIGNAL) = 45 15:50:20.477077 gettid() = 24520 15:50:20.477234 recvmsg(4, ], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC>, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 52 15:50:20.477417 sendmsg(4, ], msg_iovlen=1, msg_controllen=0, msg_flags=0>, MSG_DONTWAIT|MSG_NOSIGNAL) = 128 15:50:20.477592 recvmsg(4, , MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) 15:50:20.477751 ppoll([], 1, , NULL, 8) = 1 ([], left ) 15:50:20.478303 recvmsg(4, ], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC>, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24 15:50:20.478607 recvmsg(4, ], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC>, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 78 15:50:20.478921 sendmsg(4, ], msg_iovlen=1, msg_controllen=0, msg_flags=0>, MSG_DONTWAIT|MSG_NOSIGNAL) = 168 15:50:20.479125 recvmsg(4, ], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC>, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24 15:50:20.479322 recvmsg(4, ], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC>, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 158 15:50:20.479582 recvmsg(4, , MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) 15:50:20.479754 ppoll([], 1, , NULL, 8) = 0 (Timeout)
How to Increase SSH Connection Timeout in Linux
SSH timeouts as a result of inactivity can be quite irritating. This usually compels you to reinitiate the connection and start all over again.
Thankfully, you can easily increase the SSH timeout limit and keep your SSH session alive even after some inactivity. This happens when either the server or the client sends null packets to the other system to keep the session alive.
Let’s now explore how you can increase the SSH connection timeout in Linux.
Increase SSH Connection Timeout
On the server, head over to the /etc/ssh/sshd_config configuration file.
$ sudo vi /etc/ssh/sshd_config
Scroll and locate the following parameters:
#ClientAliveInterval #ClientAliveCountMax
The ClientAliveInterval parameter specifies the time in seconds that the server will wait before sending a null packet to the client system to keep the connection alive.
On the other hand, the ClientAliveCountMax parameter defines the number of client alive messages which are sent without getting any messages from the client. If this limit is reached while the messages are being sent, the sshd daemon will drop the session, effectively terminating the ssh session.
The timeout value is given by the product of the above parameters i.e.
Timeout value = ClientAliveInterval * ClientAliveCountMax
For example, let’s say you have defined your parameters as shown:
ClientAliveInterval 1200 ClientAliveCountMax 3
The Timeout value will be 1200 seconds * 3 = 3600 seconds. This is an equivalent of 1 hour, which implies that your ssh session will remain alive for idle time of 1 hour without dropping.
Alternatively, you can achieve the same result by specifying the ClientAliveInterval parameter alone.
Once done, reload the OpenSSH daemon for the changes to come into effect.
$ sudo systemctl reload sshd
Conclusion
As an SSH security measure, it’s always advisable not to set the SSH timeout value to a huge value. This is to prevent someone from walking by and hijacking your session when you are away for an extended period of time. And that’s it for this topic.
This is James, a certified Linux administrator and a tech enthusiast who loves keeping in touch with emerging trends in the tech world. When I’m not running commands on the terminal, I’m taking listening to some cool music. taking a casual stroll or watching a nice movie.
Each tutorial at TecMint is created by a team of experienced Linux system administrators so that it meets our high-quality standards.
Related Posts
7 thoughts on “How to Increase SSH Connection Timeout in Linux”
This “solution” to set an idle timeout seems quite common on the internet, but it’s not actually correct. I am looking for a way to get the ssh daemon to enforce an idle timeout for users, which it seems many others are also looking for. Unfortunately, this is not what ClientAliveInterval and ClientAliveMaxCount do. If you set ClientAliveInterval to a non-zero value, the server will send ClientAlive messages over the encrypted channel if it doesn’t see traffic from the client for that many seconds. This allows the client to respond over the channel that it is still alive and allows the server to clean up sessions where either the network connection has been interrupted or the client has died without gracefully disconnecting. So if you set the interval to 60 and the MaxCount to 5, then you have some clients unexpectedly die due to a power failure or become inaccessible due to a network outage, the session will be killed off on the server about 5 minutes later. What it won’t do is kill off the session if the user walks away from their terminal for more than 5 minutes. That’s the problem I’m really trying to solve. So far, the best solution I can find for that is to set the TMOUT environment variable in bash, although this only works at the primary shell prompt. If you happen to walk away whilst editing a file in vi or something like that, you again have an effectively infinite idle timeout. The one thing that you can use ClientAliveInterval to solve is if you have a firewall timing out your NAT session after an annoyingly short idle time. This was the initial problem I set out to solve. When working on 3 screens with 2 or 3 shell sessions open, I would often encounter the problem when working predominantly in one window, the other windows would freeze after about 30 minutes. I’d then need to wait about 5 minutes for the client to finally time out and realize that the TCP connection was dead and exit. Setting ClientAliveInterval to a shorter value than the firewall’s timeout value solved that problem by forcing ClientAlive messages to be sent over the connection periodically if there was no other traffic and thereby keeping the connection alive on the firewall. With my current ClientAlive Interval=30,MaxCount=3> settings, my sessions would die after 90 seconds of inactivity if this article was correct. In actuality, they’ll happily stay open for days if I don’t manually end them. If this sounds similar to your problem, then you probably want to set ClientAliveInterval to a relatively short time, like 60 seconds, rather than 1200 or 5000 like the earlier commenters. That will get rid of annoying short timeouts due to the network or similar idle timeouts outside of sshd and your shell, but it does create the new problem of user sessions that may never timeout when idle. The TMOUT environment variable provides a partial solution, but still has holes. Ideally, I wish there was an option to have sshd enforce an idle timeout based on no console activity, either input or output but so far there doesn’t seem to be an option to get sshd to do that. Reply
I tried to reload sshd but my terminal still times out. I’ve configured ClientAliveInterval 5000. Do you have any idea? Reply
I did like but you said in the post, but my ssh connection disconnect after about 30 minutes with the below error : client_loop: send disconnect: Broken pipe It happened when I try to install along with automatade script and I have no control over my session to execute any command. because the script is progressing. i set “ClientAliveInterval 1200” and “ClientAliveCountMax 3” in sshd_config Reply
At least in Ubuntu for OpenSSH, it looks like this “ClientAliveInterval” setting was a hack and no longer supported as a connection timeout setting according to this August 2020 post: https://askubuntu.com/a/1265510 Reply
Hi, I am looking for a parameter that can handle the server timeout request for an SSH connection. In other words, if a user is trying to establish a connection with an SSH Server (which doesn’t exist), then how long can we keep the connection request alive, using that parameter. Kindly suggest the same. Regards Reply