errors.but

putty

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
\e{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.

\H{errors-access-denied} \q{Access denied}, \q{Authentication refused}

Various forms of this error are printed in the PuTTY window, or
written to the PuTTY Event Log (see \k{using-eventlog}) 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
\k{config-ssh-bug-ignore1} and possibly \k{config-ssh-bug-plainpw1}.

\H{errors-crc} \q{Incorrect \i{CRC} received on packet} or \q{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.

A known server problem which can cause this error is described in
\k{faq-openssh-bad-openssl} in the FAQ.

\H{errors-garbled} \q{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 \q{Miscomputes SSH-2 encryption keys} on the Bugs
panel (see \k{config-ssh-bug-derivekey2}).

Another known server problem which can cause this error is described
in \k{faq-openssh-bad-openssl} in the FAQ.

\H{errors-x11-proxy} \q{PuTTY X11 proxy: \e{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 \k{using-x-forwarding}) 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 \q{fred}), and then used
the Unix \c{su} command to become another user (typically \q{root}).
The original user, \q{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
(\q{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, \e{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 \c{su} to become. How you do
this depends on your particular system; in fact many modern versions
of \c{su} do it automatically.

\H{errors-connaborted} \q{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
\k{config-ssh-kex-rekey} for more about key re-exchange.)

(It can also occur if you are using keepalives in your connection.
Other people have reported that keepalives \e{fix} this error for
them. See \k{config-keepalive} 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.

\H{errors-connreset} \q{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 \i{firewall} or a \i{NAT router} which has timed the
connection out. See \k{faq-idleout} in the FAQ for more details. You
may be able to improve the situation by using keepalives; see
\k{config-keepalive} 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.

\H{errors-connrefused} \q{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.

\H{errors-conntimedout} \q{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.

\i{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 \k{config-ssh-kex-rekey}) or due to
keepalives (\k{config-keepalive}).