Once a connection is successfully established, the SSH protocol negotiates an encrypted connection with the client based on establishing trust. Before you can even verify who you are on the system, the system attempts to establish an encryption method with your client. There are a few unique issues that can occur in this scope, and this tutorial covers how to identify them, how to resolve them, and additional resources to prevent them.
When you connect to a server through an SSH client, the server attempts to identify itself using a host key. In situations where the host key changes, you may see a warning such as:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
...
In PuTTY, you get an equally ominous warning:
WARNING - POTENTIAL SECURITY BREACH!
The server's host key does not match the one PuTTY has
cached in the registry. This means that either the
Server administrator has changed the host key, or you
...
Common causes for this issue include:
To resolve this, you can clear your host keys.
In some situations, connectivity is established at the socket level but disconnects during the host key verification phase.
OpenSSH clients may show this error:
Connection closed by 203.0.113.0 port 22
PuTTY may show this error:
Server Unexpectedly closed network connection
Some common issues that may cause this error include:
In a situation like this, a more thorough review of the protocol output is necessary. In most cases, you need to investigate this from the server through the Recovery Console. From there, make sure that the service is currently running and bound to the expected port.
When initiating the SSH protocol, a shared secret is generated through a cipher negotiated between the client and the host.
An OpenSSH client may show an error like this:
Unable to negotiate with 203.0.113.0: no matching key exchange method found.
Their offer: diffie-hellman-group1-sha1
PuTTY may show an error like this:
Couldn't agree a client-to-server cipher (available: aes128-ctr, aes192-ctr, aes256-ctr)
Some common issues that may cause this error include:
To resolve this issue, you need to customize the supported ciphers in your SSH client.
Host keys are typically stored in the ~/.ssh/known_hosts
file on OpenSSH client implementations. PuTTY typically stores these in the Windows Registry (HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys
).
In PuTTY, use the window that opens when you connect to select Yes to allow the connection and update the registry. Alternatively, you can manually remove the entry.
On an OpenSSH client, you can find the host entry in the ~/.ssh/known_hosts
file and manually remove it. Another option is to use the ssh-keygen
command:
ssh-keygen -R 203.0.113.0
This attempts to access and clear the matching host entry in the known_hosts
file:
# Host 203.0.113.0 found: line 2
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.old
You can then try to reconnect to your server normally.
If your SSH host doesn’t have its own private key to generate a shared secret, the connection is aborted. To check that the host has a private key, look in the /etc/ssh
directory for a group of files named like sshd_host_*_key
with corresponding .pub
files.
If the files don’t exist, you need to regenerate them. You can do this using ssh-keygen
as root or with sudo
:
ssh-keygen -A
The output reports the actions taken, including a list of the keys generated:
ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519
You can then try to reconnect to your server normally.
You can customize the supported SSH ciphers on your client machine when you need support for a deprecated cipher like SHA1. This is not a very common issue. It typically happens when you use a modern SSH client to connect to an old SSH server that hasn’t yet disabled weaker ciphers.
In OpenSSH, you can configure SHA1 using the KexAlgorithms
option on the command line:
openssh -oKexAlgorithms=+diffie-hellman-group1-sha1 [email protected]
PuTTY should already include the Diffie-Hellman group 1 option in the Connection > SSH > Kex configuration.
If you need further help, you can open a support ticket. Make sure to include the following information:
Including all the above diagnostic information and clarifying where you are encountering the issue when trying to connect can help us quickly get up to speed with where your need on the issue is.