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.9 ‘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.26.1
and possibly section 4.26.2
. 10.10 ‘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 section 4.21.4
and section 4.21.5
. 10.11 ‘Incorrect CRC received on packet’ or ‘Incorrect MAC 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.
A known server problem which can cause this error is described in question A.7.16
in the FAQ. 10.12 ‘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.26.7
) or ‘Ignores SSH-2 maximum packet size’ (see section 4.26.11
) on the Bugs panel . Another known server problem which can cause this error is described in question A.7.16
in the FAQ. 10.13 ‘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