предыдущая глава | содержание | следующая глава
- 10.1 «The server’s host key is not cached in the registry»
- 10.2 «WARNING — POTENTIAL SECURITY BREACH!»
- 10.3 «SSH protocol version 2 required by our configuration but remote only provides (old, insecure) SSH-1»
- 10.4 «The first cipher supported by the server is … below the configured warning threshold»
- 10.5 «Remote side sent disconnect message type 2 (protocol error): «Too many authentication failures for root»»
- 10.6 «Out of memory»
- 10.7 «Internal error», «Internal fault», «Assertion failed»
- 10.8 «Unable to use key file», «Couldn’t load private key», «Couldn’t load this key»
- 10.9 «Server refused our key», «Server refused our public key», «Key refused»
- 10.10 «Access denied», «Authentication refused»
- 10.11 «No supported authentication methods available»
- 10.12 «Incorrect MAC received on packet» or «Incorrect CRC received on packet»
- 10.13 «Incoming packet was garbled on decryption»
- 10.14 «PuTTY X11 proxy: various errors»
- 10.15 «Network error: Software caused connection abort»
- 10.16 «Network error: Connection reset by peer»
- 10.17 «Network error: Connection refused»
- 10.18 «Network error: Connection timed out»
- 10.19 «Network error: Cannot assign requested address»
This chapter lists a number of common error messages which PuTTY and its associated tools can produce, and explains what they mean in more detail.
We do not attempt to list all error messages here: there are many which should never occur, and some which should be self-explanatory. If you get an error message which is not listed in this chapter and which you don’t understand, report it to us as a bug (see appendix B) and we will add documentation for it.
10.1 «The server’s host key is not cached in the registry»
This error message occurs when PuTTY connects to a new SSH server. Every server identifies itself by means of a host key; once PuTTY knows the host key for a server, it will be able to detect if a malicious attacker redirects your connection to another machine.
If you see this message, it means that PuTTY has not seen this host key before, and has no way of knowing whether it is correct or not. You should attempt to verify the host key by other means, such as asking the machine’s administrator.
If you see this message and you know that your installation of PuTTY has connected to the same server before, it may have been recently upgraded to SSH protocol version 2. SSH protocols 1 and 2 use separate host keys, so when you first use SSH-2 with a server you have only used SSH-1 with before, you will see this message again. You should verify the correctness of the key as before.
See section 2.2 for more information on host keys.
10.2 «WARNING — POTENTIAL SECURITY BREACH!»
This message, followed by «The server’s host key does not match the one PuTTY has cached in the registry», means that PuTTY has connected to the SSH server before, knows what its host key should be, but has found a different one.
This may mean that a malicious attacker has replaced your server with a different one, or has redirected your network connection to their own machine. On the other hand, it may simply mean that the administrator of your server has accidentally changed the key while upgrading the SSH software; this shouldn’t happen but it is unfortunately possible.
You should contact your server’s administrator and see whether they expect the host key to have changed. If so, verify the new host key in the same way as you would if it was new.
See section 2.2 for more information on host keys.
10.3 «SSH protocol version 2 required by our configuration but remote only provides (old, insecure) SSH-1»
By default, PuTTY only supports connecting to SSH servers that implement SSH protocol version 2. If you see this message, the server you’re trying to connect to only supports the older SSH-1 protocol.
If the server genuinely only supports SSH-1, then you need to either change the «SSH protocol version» setting (see section 4.19.4), or use the -1 command-line option; in any case, you should not treat the resulting connection as secure.
You might start seeing this message with new versions of PuTTY (from 0.68 onwards) where you didn’t before, because it used to be possible to configure PuTTY to automatically fall back from SSH-2 to SSH-1. This is no longer supported, to prevent the possibility of a downgrade attack.
10.4 «The first cipher supported by the server is … below the configured warning threshold»
This occurs when the SSH server does not offer any ciphers which you have configured PuTTY to consider strong enough. By default, PuTTY puts up this warning only for Blowfish, single-DES, and Arcfour encryption.
See section 4.22 for more information on this message.
(There are similar messages for other cryptographic primitives, such as host key algorithms.)
10.5 «Remote side sent disconnect message type 2 (protocol error): «Too many authentication failures for root»»
This message is produced by an OpenSSH (or Sun SSH) server if it receives more failed authentication attempts than it is willing to tolerate.
This can easily happen if you are using Pageant and have a large number of keys loaded into it, since these servers count each offer of a public key as an authentication attempt. This can be worked around by specifying the key that’s required for the authentication in the PuTTY configuration (see section 4.23.8); PuTTY will ignore any other keys Pageant may have, but will ask Pageant to do the authentication, so that you don’t have to type your passphrase.
On the server, this can be worked around by disabling public-key authentication or (for Sun SSH only) by increasing MaxAuthTries in sshd_config.
10.6 «Out of memory»
This occurs when PuTTY tries to allocate more memory than the system can give it. This may happen for genuine reasons: if the computer really has run out of memory, or if you have configured an extremely large number of lines of scrollback in your terminal. PuTTY is not able to recover from running out of memory; it will terminate immediately after giving this error.
However, this error can also occur when memory is not running out at all, because PuTTY receives data in the wrong format. In SSH-2 and also in SFTP, the server sends the length of each message before the message itself; so PuTTY will receive the length, try to allocate space for the message, and then receive the rest of the message. If the length PuTTY receives is garbage, it will try to allocate a ridiculous amount of memory, and will terminate with an «Out of memory» error.
This can happen in SSH-2, if PuTTY and the server have not enabled encryption in the same way (see question A.7.3 in the FAQ).
This can also happen in PSCP or PSFTP, if your login scripts on the server generate output: the client program will be expecting an SFTP message starting with a length, and if it receives some text from your login scripts instead it will try to interpret them as a message length. See question A.7.4 for details of this.
10.7 «Internal error», «Internal fault», «Assertion failed»
Any error beginning with the word «Internal» should never occur. If it does, there is a bug in PuTTY by definition; please see appendix B and report it to us.
Similarly, any error message starting with «Assertion failed» is a bug in PuTTY. Please report it to us, and include the exact text from the error message box.
10.8 «Unable to use key file», «Couldn’t load private key», «Couldn’t load this key»
Various forms of this error are printed in the PuTTY window, or written to the PuTTY Event Log (see section 3.1.3.1) when trying public-key authentication, or given by Pageant when trying to load a private key.
If you see one of these messages, it often indicates that you’ve tried to load a key of an inappropriate type into PuTTY, Plink, PSCP, PSFTP, or Pageant.
You may have tried to load an SSH-2 key in a «foreign» format (OpenSSH or ssh.com) directly into one of the PuTTY tools, in which case you need to import it into PuTTY’s native format (*.PPK) using PuTTYgen – see section 8.2.12.
Alternatively, you may have specified a key that’s inappropriate for the connection you’re making. The SSH-2 and the old SSH-1 protocols require different private key formats, and a SSH-1 key can’t be used for a SSH-2 connection (or vice versa).
10.9 «Server refused our key», «Server refused our public key», «Key refused»
Various forms of this error are printed in the PuTTY window, or written to the PuTTY Event Log (see section 3.1.3.1) when trying public-key authentication.
If you see one of these messages, it means that PuTTY has sent a public key to the server and offered to authenticate with it, and the server has refused to accept authentication. This usually means that the server is not configured to accept this key to authenticate this user.
This is almost certainly not a problem with PuTTY. If you see this type of message, the first thing you should do is check your server configuration carefully. Common errors include having the wrong permissions or ownership set on the public key or the user’s home directory on the server. Also, read the PuTTY Event Log; the server may have sent diagnostic messages explaining exactly what problem it had with your setup.
Section 8.3 has some hints on server-side public key setup.
10.10 «Access denied», «Authentication refused»
Various forms of this error are printed in the PuTTY window, or written to the PuTTY Event Log (see section 3.1.3.1) during authentication.
If you see one of these messages, it means that the server has refused all the forms of authentication PuTTY has tried and it has no further ideas.
It may be worth checking the Event Log for diagnostic messages from the server giving more detail.
This error can be caused by buggy SSH-1 servers that fail to cope with the various strategies we use for camouflaging passwords in transit. Upgrade your server, or use the workarounds described in section 4.28.11 and possibly section 4.28.12.
10.11 «No supported authentication methods available»
This error indicates that PuTTY has run out of ways to authenticate you to an SSH server. This may be because PuTTY has TIS or keyboard-interactive authentication disabled, in which case see section 4.23.4 and section 4.23.5.
10.12 «Incorrect MAC received on packet» or «Incorrect CRC received on packet»
This error occurs when PuTTY decrypts an SSH packet and its checksum is not correct. This probably means something has gone wrong in the encryption or decryption process. It’s difficult to tell from this error message whether the problem is in the client, in the server, or in between.
In particular, if the network is corrupting data at the TCP level, it may only be obvious with cryptographic protocols such as SSH, which explicitly check the integrity of the transferred data and complain loudly if the checks fail. Corruption of protocols without integrity protection (such as HTTP) will manifest in more subtle failures (such as misdisplayed text or images in a web browser) which may not be noticed.
Occasionally this has been caused by server bugs. An example is the bug described at section 4.28.8, although you’re very unlikely to encounter that one these days.
In this context MAC stands for Message Authentication Code. It’s a cryptographic term, and it has nothing at all to do with Ethernet MAC (Media Access Control) addresses, or with the Apple computer.
10.13 «Incoming packet was garbled on decryption»
This error occurs when PuTTY decrypts an SSH packet and the decrypted data makes no sense. This probably means something has gone wrong in the encryption or decryption process. It’s difficult to tell from this error message whether the problem is in the client, in the server, or in between.
If you get this error, one thing you could try would be to fiddle with the setting of «Miscomputes SSH-2 encryption keys» (see section 4.28.10) or «Ignores SSH-2 maximum packet size» (see section 4.28.5) on the Bugs panel.
10.14 «PuTTY X11 proxy: various errors»
This family of errors are reported when PuTTY is doing X forwarding. They are sent back to the X application running on the SSH server, which will usually report the error to the user.
When PuTTY enables X forwarding (see section 3.4) it creates a virtual X display running on the SSH server. This display requires authentication to connect to it (this is how PuTTY prevents other users on your server machine from connecting through the PuTTY proxy to your real X display). PuTTY also sends the server the details it needs to enable clients to connect, and the server should put this mechanism in place automatically, so your X applications should just work.
A common reason why people see one of these messages is because they used SSH to log in as one user (let’s say «fred»), and then used the Unix su command to become another user (typically «root»). The original user, «fred», has access to the X authentication data provided by the SSH server, and can run X applications which are forwarded over the SSH connection. However, the second user («root») does not automatically have the authentication data passed on to it, so attempting to run an X application as that user often fails with this error.
If this happens, it is not a problem with PuTTY. You need to arrange for your X authentication data to be passed from the user you logged in as to the user you used su to become. How you do this depends on your particular system; in fact many modern versions of su do it automatically.
10.15 «Network error: Software caused connection abort»
This is a generic error produced by the Windows network code when it kills an established connection for some reason. For example, it might happen if you pull the network cable out of the back of an Ethernet-connected computer, or if Windows has any other similar reason to believe the entire network has become unreachable.
Windows also generates this error if it has given up on the machine at the other end of the connection ever responding to it. If the network between your client and server goes down and your client then tries to send some data, Windows will make several attempts to send the data and will then give up and kill the connection. In particular, this can occur even if you didn’t type anything, if you are using SSH-2 and PuTTY attempts a key re-exchange. (See section 4.20.2 for more about key re-exchange.)
(It can also occur if you are using keepalives in your connection. Other people have reported that keepalives fix this error for them. See section 4.14.1 for a discussion of the pros and cons of keepalives.)
We are not aware of any reason why this error might occur that would represent a bug in PuTTY. The problem is between you, your Windows system, your network and the remote system.
10.16 «Network error: Connection reset by peer»
This error occurs when the machines at each end of a network connection lose track of the state of the connection between them. For example, you might see it if your SSH server crashes, and manages to reboot fully before you next attempt to send data to it.
However, the most common reason to see this message is if you are connecting through a firewall or a NAT router which has timed the connection out. See question A.7.8 in the FAQ for more details. You may be able to improve the situation by using keepalives; see section 4.14.1 for details on this.
Note that Windows can produce this error in some circumstances without seeing a connection reset from the server, for instance if the connection to the network is lost.
10.17 «Network error: Connection refused»
This error means that the network connection PuTTY tried to make to your server was rejected by the server. Usually this happens because the server does not provide the service which PuTTY is trying to access.
Check that you are connecting with the correct protocol (SSH, Telnet or Rlogin), and check that the port number is correct. If that fails, consult the administrator of your server.
10.18 «Network error: Connection timed out»
This error means that the network connection PuTTY tried to make to your server received no response at all from the server. Usually this happens because the server machine is completely isolated from the network, or because it is turned off.
Check that you have correctly entered the host name or IP address of your server machine. If that fails, consult the administrator of your server.
Unix also generates this error when it tries to send data down a connection and contact with the server has been completely lost during a connection. (There is a delay of minutes before Unix gives up on receiving a reply from the server.) This can occur if you type things into PuTTY while the network is down, but it can also occur if PuTTY decides of its own accord to send data: due to a repeat key exchange in SSH-2 (see section 4.20.2) or due to keepalives (section 4.14.1).
10.19 «Network error: Cannot assign requested address»
This means that the operating system rejected the parameters of the network connection PuTTY tried to make, usually without actually trying to connect to anything, because they were simply invalid.
A common way to provoke this error is to accidentally try to connect to port 0, which is not a valid port number.
Fixing the error has never been any easier
by Loredana Harsana
Loredana is a passionate writer with a keen interest in PC software and technology. She started off writing about mobile phones back when Samsung Galaxy S II was… read more
Updated on September 14, 2022
Reviewed by
Vlad Turiceanu
Passionate about technology, Windows, and everything that has a power button, he spent most of his time developing new skills and learning more about the tech world. Coming… read more
- PuTTY is an open-source tool that uses network protocols like Telnet and rlogin with an xterm terminal emulator for Windows and UNIX systems.
- Many users have reported the Fatal Error, Network Error: Software Caused Connection Abort.
- Network firewalls terminating the connections if these remains idle for some time on the server is a common underlying cause.
PuTTY is a cross-platform program that uses SSH (Secure Shell) protocols to provide secure communication between networks, systems, and applications over an unsecured network. But many reported the Software caused connection abort error in PuTTY.
There can be several reasons why you may receive this specific error message, but one of the most common is a shaky Internet connection. If your Internet connection isn’t as stable as it could be, it will cause intermittent interruptions in your session that could result in this error message.
Another reason you might get this error message is if you leave your session open for an extended period. PuTTY can be configured to abort the connection when it has been left open for a specified time.
PuTTY is a utility that can be used to transport data in order to send and receive files swiftly and securely. The program also allows for serial port connections, which support Telnet, rlogin, SCP, SFTP, and other protocols.
PuTTY has several advantages, especially while working remotely. It’s simpler to set up and more reliable than VNC or other protocols built into the operating system.
It is also more persistent in comparison to others, as a remote connection can be resumed as soon as the connection is restored after an interruption. It is a completely free and open-source software package and has an easy-to-use graphical user interface.
Now that you have a basic understanding of the tool, let’s find out how to fix the Software caused connection abort error in PuTTY.
How can I resolve the Network error: Software caused connection abort in PuTTY?
1. Check your Internet connection
- Press Windows + R to open Run, enter cmd in the text field, and click OK.
- Paste the following command while replacing the IP address with yours, and then hit Enter:
ping IP address -t
- If you see more than one message like Request timed out, press Ctrl+C to stop the operation, and note the Lost rate in the ping statistics.
The lost packets will tell you the Internet’s condition, packet loss, and connection drop rate. The simple way to combat an unreliable Internet connection is to restart PuTTY and re-establish the connection.
Some PC issues are hard to tackle, especially when it comes to missing or corrupted system files and repositories of your Windows.
Be sure to use a dedicated tool, such as Fortect, which will scan and replace your broken files with their fresh versions from its repository.
If you still encounter the Software caused connection abort error in PuTTY, try the following method.
- How to Hard Reset Your HP Laptop [3 Quick Ways]
- USB Shortcut Virus: How to Permanently Remove It
- Event ID 5136: A Directory Service Object was Modified [Fix]
- Event ID 7045: A Service was Installed in the System [Fix]
- What is mbamservice.exe & How to Stop its High Memory Usage
2. Configure PuTTY to enable TCP keepalives
- Open the PuTTY software, and then select Connection from the navigation pane on the left.
- Mark the checkbox for Enable TCP keepalives (SO_KEEPALIVE option) under Low-level TCP connection options.
- Next, set the value of Seconds between keepalives(0 to turn off) to somewhere between 5 to 30 seconds.
- Click Open and check if the idle connection remains open for the set duration.
Your network routers and/or firewalls usually keep track of all the connections. However, they may assume that a connection is dead if no data is transferred in either direction after a certain time.
This happens because the firewall software has a timeout, closes the connection after that timer runs out, and leads to the Software caused connection abort error in PuTTY.
You can solve this issue by configuring PuTTY to send null packets and TCP keepalives every few seconds. It will make sure that the session does not abort even if the connection is not transmitting data.
It is recommended to keep the keepalive value comparatively low. The keepalives are not always helpful and can make things worse. Because it will increase the probability of PuTTY attempting to send data during a break in connectivity.
3. Switch to static IP
- Press Windows + R to open Run, enter ncpa.cpl in the text field, and click OK.
- Right-click on the active network, and select Properties.
- Next, select Internet Protocol Version 4 (TCP/IPv4), and click on Properties.
- Select the Use the follow DNS server addresses, enter the following values in the provided field, and click on OK.
- Preferred DNS server: 8.8.8.8
- Alternate DNS server: 8.8.4.4
Once done, flush the DNS cache, and things should now be up and running.
That’s it! You would have the Software caused connection abort error fixed in PuTTY by now and the utility up and running like before.
Also, find out how to fix the Connection timed out Network error in PuTTY, another common issue reported by many.
Which one of these solutions works for you? Share your experience in the comments section below.
Troubleshooting the PuTTY Network Error
Software caused connection abort
Read what PuTTY has to say about the error
This is a generic error produced by the Windows network code when it kills an established connection for some reason. For example, it might happen if you pull the network cable out of the back of an Ethernet-connected computer, or if Windows has any other similar reason to believe the entire network has become unreachable.
Windows also generates this error if it has given up on the machine at the other end of the connection responding to it. If the network between your client and server goes down and your client then tries to send some data, Windows will make several attempts to send the data and will then give up and kill the connection. In particular, this can occur even if you didn’t type anything, if you are using SSH-2 and PuTTY attempts a key re-exchange.
(It can also occur if you are using keepalives in your connection. Other people have reported that keepalives fix this error for them. (There are pros and cons of keepalives.))
We are not aware of any reason why this error might occur that would represent a bug in PuTTY. The problem is between you, your Windows system, your network and the remote system.
Try a different SSH client
Most likely the problem exists somewhere between PuTTY and the target SSH server. To provide evidence for this, use a different SSH client like (http://kitty.9bis.net) and see if the problem happens on that as well. It probably will which will isolate the problem away from PuTTY.
Suspect spotty Internet connection
The problem may be the spotty Internet connection. Internet Connectivity Monitoring the uptime of an Internet connection is a good way of determining if your ISP are losing packets and is to blame for PuTTY going down. Get some software that tests the uptime of an Internet connection. For example, http://code.google.com/p/internetconnectivitymonitor/. Frequent and long disconnections from the Internet is a breach of ISP service requirements. If this is the case, it will be difficult to prove it’s the ISP’s fault, as tech support automatically blames these sorts of issues on your computer, OS, router, and wiring to your home. If you are using cable Internet and living out in the boonies, it could be possible that defective hardware in your neighbor’s homes could be sending static on the line for a few seconds/minutes when they first turn it on. Finally, it’s possible that there is defective hardware in the ISP’s network to your home. The cost to ISPs to replace their hardware is so high, that often times they won’t do it unless there are enough subscribers in an area to warrent the cost.
Suspect the wired/wireless router
Are you connecting through a wired/wireless router? How old is it? Your router might be the problem. Old wireless and wired technology can get old and drop connections sporadically and restart them, causing PuTTY to die. Remove these components from the equation and see if that solves the problem. Try a wired connection and/or different router to see if that fixes the problem. I had a Linksys wireless router suffer this slow death and drop connections and restart them.
Suspect the operating system providing the SSH connection
The computer you are connecting to with SSH has a policy for number of seconds to keep SSH connections alive. This number is set low for security reasons, and you could increase it. Where this setting is depends on what operating system you are using that provides SSH.
If you are using PuTTY through a virtual machine
If you are using PuTTY passing through a virtual machine, there may be a policy on the virtual machine which is breaking your SSH connection to the server when it thinks it is inactive. Increasing these values depends on which virtual machine software and operating system you are using.
If the Internet connection is bad, SSH client connection workarounds:
If your ISP provides an unstable connection then you could make the disconnections less painful with «ssh autologin». What you do is generate a public and private key. And you tell your foreign server to automatically let in anyone who provides an accurate private key. It doesn’t solve your problem completely, but when the Internet outage happens, all you do is close the window, double click an icon, and you are immediately taken back to your home folder command line without entering a username/password.
This will help you with that:
Is there a way to «auto login» in PuTTY with a password?
Last updated on February 7th, 2021 | 22 replies
Windows can trigger this error if PuTTY has given up on the machine at the other end of the connection. In this article we will configure PuTTY to attempt to keep idle connections alive.
TCP Keepalives
Some network routers and firewalls need to keep track of all connections through them. Usually, these firewalls will assume a connection is dead if no data is transferred in either direction after a certain time interval.
This can cause PuTTY sessions to be unexpectedly closed by the firewall if no traffic is seen in the session for some time, which will trigger the error: “Network Error: Software Caused Connection Abort”.
To solve this issue, you can configure PuTTY to send null packets and TCP keepalives every few seconds.
Configure PuTTY
In the left-hand menu pane, select Connection
In the field beside Seconds between keepalives, enter 5.
Check Enable TCP Keepalives (SO_KEEPALIVE option)
Now click Open and leave the SSH connection idle for a while to see if it stays up.
If you are using a PuTTY session profile, don’t forget to Save your profile with these new settings.
Still Getting Disconnected?
Check for an unreliable Internet connection
If you are still getting the error “Network Error: Software Caused Connection Abort” despite enabling TCP Keepalives, the problem may be due to an unreliable Internet connection. Monitoring your pings is a good way of determining if your internet connection is dropping packets and to blame for PuTTY disconnecting.
Open Windows Command Prompt and run ping google.com -t (or the IP address of your remote server) and leave it running while your SSH connection is open. If you see even one message saying “Request timed out”, this indicates an internet connectivity issue, which may cause PuTTY to disconnect with “Network Error: Software Caused Connection Abort”.
You can also try some software that tests the uptime of an Internet connection. See: Internet Connectivity Monitor.
Try a different SSH client
Try using a different SSH client like (http://kitty.9bis.net) and see if the problem happens on that as well. If it does, you can isolate the problem away from PuTTY.
TCP Keepalives are not always helpful..
TCP Keepalives help if you have a firewall which drops your connection after an idle period; but if the network between you and the server suffers from breaks in connectivity, keepalives can actually make things worse.
If a session is idle, and connectivity is temporarily lost between the endpoints, but the connectivity is restored before either side tries to send anything, then there will be no problem – neither endpoint will notice that anything was wrong.
However, if one side does send something during the break, it will repeatedly try to re-send, and eventually give up and abandon the connection. Then when connectivity is restored, the other side will find that the first side doesn’t believe there is an open connection any more.
TCP Keepalives can make this sort of problem worse, because they increase the probability that PuTTY will attempt to send data during a break in connectivity. Other types of periodic network activity can cause this behaviour; in particular, SSH-2 re-keys can have this effect.
Therefore, you might find that TCP Keepalives help connection loss, or you might find they make it worse, depending on what kind of network problems you have between you and the server.
Found a Solution Yet?
Let us all know in the comments as this appears to be quite an elusive problem for many!
While You’re Here..
Sick of entering your Linux password every time you log in via PuTTY? See:
- Saving your PuTTY username and password in a Windows Shortcut
- PuTTY and SSH Key-Based Authentication
Make sure to keep your PuTTY settings backed up or copy them to another PC:
- How to Backup and Copy PuTTY Sessions and Settings to Another PC
Did you know you can use PuTTY to set up a secure tunnel to your Linux box and then connect via VNC?
- How to Install VNC and Use PuTTY to Connect from Windows
Let me know if this helped. Follow me on Twitter, Facebook and YouTube, or 🍊 buy me a smoothie.
p.s. I increased my AdSense revenue by 200% using AI 🤖. Read my Ezoic review to find out how.
10.15 ‘Network error: Software caused connection abort’
This is a generic error produced by the Windows network code when it kills an established connection for some reason. For example, it might happen if you pull the network cable out of the back of an Ethernet-connected computer, or if Windows has any other similar reason to believe the entire network has become unreachable.
Windows also generates this error if it has given up on the machine at the other end of the connection ever responding to it. If the network between your client and server goes down and your client then tries to send some data, Windows will make several attempts to send the data and will then give up and kill the connection. In particular, this can occur even if you didn’t type anything, if you are using SSH-2 and PuTTY attempts a key re-exchange. (See section 4.19.2 for more about key re-exchange.)
(It can also occur if you are using keepalives in your connection. Other people have reported that keepalives fix this error for them. See section 4.13.1 for a discussion of the pros and cons of keepalives.)
We are not aware of any reason why this error might occur that would represent a bug in PuTTY. The problem is between you, your Windows system, your network and the remote system.