I have a VPS running Debian 7, that I connect to using PuTTY from my Windows machine. Most of the time, PuTTY connects fine and I can log in fine. However, occasionally, PuTTY will report that Connection Timeout.

When this happened last time, I attempted to telnet to the port that is running SSH and it could not connect. I then attempted to telnet to another port on the VPS that I knew was running a service and it connected fine.

When it starts to "play up", if I try 5-10 times to connect, I can successfully connect. I checked the syslog and I could not see anything interesting in there that could help with this problem. If it is worth anything, when I do connect to the server when it is "playing up", it appears to be slow (I will type a command and it will take a second or two to appear in the SSH window).

I don't believe this to be a firewall issue as it will work most of time, then sometimes just not work. Maybe my host is doing some maintenance?

EDIT: TCPKeepAlive is enabled. It played up again just now and when attempting to telnet to the SSH port, it could in fact connect. Weird.

  • it can be useful to verify your PuTTY settings and you sshd server settings first. do you activate TCPKeepAlive on /etc/ssh/sshd_config for examples ? Dec 31, 2015 at 11:18
  • Thanks for the reply Mike. TCPKeepAlive is enabled, yes. It has just happened again now and I could telnet to the SSH port when PuTTY would report the connection had timed out when trying to connect. Dec 31, 2015 at 11:29
  • 1
    Have you called the support for your VPS?
    – xenoid
    Dec 7, 2017 at 10:38

3 Answers 3


To diagnose, first you have to use a verbose mode of putty.exe.

Open cmd and use :

putty.exe -v -ssh user@]host

The -v will show you many more information.

To avoid close connections, verify your settings :

On PuTTY (Win) : go to session properties > connection, and under Sending of null packets to keep session active, set Seconds between keepalives (0 to turn off) to e.g. 300 (5 minutes).

On Linux (ssh) : To enable the keep alive system-wide :

  • for all users: edit /etc/ssh/ssh_config.
  • just for you: edit ~/.ssh/config instead.

Insert the following:

Host *
    ServerAliveInterval 300
    ServerAliveCountMax 2

You can also make your OpenSSH server keep alive all connections with clients by adding the following to /etc/ssh/sshd_config:

KeepAlive yes
ClientAliveInterval 300
ClientAliveCountMax 2

These settings will make the SSH client or server send a null packet to the other side every 300 seconds (5 minutes), and give up if it doesn’t receive any response after 2 tries, at which point the connection is likely to have been discarded anyway.

From the ssh_config man page:

ServerAliveCountMax Sets the number of server alive messages (see below) which may be sent without ssh(1) receiving any messages back from the server. If this threshold is reached while server alive messages are being sent, ssh will disconnect from the server, terminating the session. It is important to note that the use of server alive messages is very different from TCPKeepAlive (below). The server alive messages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by TCPKeepAlive is spoofable. The server alive mechanism is valuable when the client or server depend on knowing when a connection has become inactive.

The default value is 3. If, for example, ServerAliveInterval (see below) is set to 15 and ServerAliveCountMax is left at the default, if the server becomes unresponsive, ssh will disconnect after approximately 45 seconds. This option applies to protocol version 2 only; in protocol version 1 there is no mechanism to request a response from the server to the server alive messages, so disconnection is the responsibility of the TCP stack.

ServerAliveInterval Sets a timeout interval in seconds after which if no data has been received from the server, ssh(1) will send a message through the encrypted channel to request a response from the server. The default is 0, indicating that these messages will not be sent to the server, or 300 if the BatchMode option is set. This option applies to protocol version 2 only. ProtocolKeepAlives and SetupTimeOut are Debian-specific compatibility aliases for this option.

  • with the putty command I get the error option "-v" not available in this tool
    – Neuron
    Dec 7, 2021 at 15:23

It sounds like you tried to rule out a broader network problem, and you probably did so correctly.

(I would always think about measuring network latency measurement, looking at ping and traceroute. Because it doesn't need to take too long to just ping and see if there's a very broad problem, which could be with your local internet connection instead.)

I think there are two common problems to be on the look out for, when you are using a VPS.

  1. If you try to run too much in a too small VPS. You can use too much memory, and then be constantly swapping data/code in and out from disk. Now your disk is very busy, and everything is slow, e.g. it takes a long time e.g. to load SSH.

    Diagnostic: monitor your memory usage.

    atop might be a convenient way to create a very coarse-grained log of memory usage and some other performance information. atop costs around 5/10M of ram to run (32-bit vs. 64-bit). This will work for a VPS based on Xen or KVM; I'm not sure how well it would work with OpenVZ (or other container-based VPS).

  2. The "noisy neighbor" problem. Sometimes caused by someone else running in to the previous problem :). In a virtual system, you are sharing hardware with many others. If some people are using more disk IOs (or possibly more memory) than "expected", the other VPS's on the same hardware will suffer.

    Monitoring can also be useful to diagnose this. However it's perhaps somewhat more difficult and specialized an issue.

It might be best to focus on being able to measure and monitor (log/graph) something approaching real-world response time of your service(s). When your VPS is primarily a public web server, this is a common desire and there are free trial/limited services that offer to do this for you.

We can conclude that a good host would provide basic advice and/or tools for both types of monitoring, but I'm not how sure common that really is :).

These types of issues will be known to your VPS provider. One diagnostic technique is to contact them and describe the problem you have been experiencing :-).


I don't know precisely why this happens (as we can see, the general consensus seems to be that there are many factors on the source, destination and network components that can affect this).

However, I have found that using scp to copy a small dummy file before doing the actual ssh seems to almost eliminate this issue in several Linux and AIX environments:

echo Copying small dummy file to $DESTINATION_IP
scp -o StrictHostKeyChecking=no -o PasswordAuthentication=no dummy.tmp testuser@$DESTINATION_IP:/tmp/. 
echo Testing ssh again
ssh -n -tt -o StrictHostKeyChecking=no -o PasswordAuthentication=no testuser@DESTINATION_IP

You must log in to answer this question.

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