Troubleshooting SSH Connection Errors - no compatible ciphers were found
- wamuyu murakaru
- Oct 25, 2024
- 5 min read
Updated: Oct 28, 2024
Recently, someone asked me to troubleshoot and fix this error message that occurred during SSH connection. So, I went digging...
Introduction
Let's begin by examining the ideal SSH connection process between a client and a server. This process involves several key steps, including connection requests, algorithm negotiations, and secure data exchange.
To illustrate this flow clearly, I created a visual representation on draw.io. This diagram serves as a quick reference for the SSH connection flow before we delve into potential causes of any errors.
What is SSH?
SSH, or Secure Shell, is a protocol designed to facilitate secure communication between a client and a server. It operates over TCP port 22 and involves a series of messages exchanged between the client and server to establish a secure connection.
By understanding this process, we can better troubleshoot issues and ensure robust security in our communications.
Request to establish a connection
The client sends a connection request to the server. The request contains the client SSH version.
Upon receipt of the message by the sever, the server sends a response to the client containing the server SSH version.
What could go wrong during this first step?
Network issues - If there are connectivity issues the request might not reach the server
Server unavailable - Server might be unreachable or not listening on port 22.
Version mismatch - If the client SSK version is incomaptible with the servers version, it could cause issues.
Firewall settings - The fw might be configured to block port 22 traffic.
These are just a few issues that could be experienced during the first step.
Negotiating a method for Key exchange
The client and server share the key algorithm list. Some examples of key algorithms include symmetric and asymmetric algorithms
Symmetric - these use the same key for encyption and decryption e.g AES, 3DES and blowfish
Asymmetric - These algorithms use different keys for encryption and decryption - A pair of keys - private and public keys. Examples RSA, DSA, ECDSA and DH
What could go wrong during this first step?
No common algorithms - If the client and server cannot agree on a key algorithm, it results in a failed handshake.
Deprecated algorithms - If the algorithms are deprecated, it poses a security risk and the handshake might fail.
Incorrect configuration on either isde might lead to mismatch
Intermediate devices between the client and server e.g firewall which might interfere with the key exchange process.
Client verifies the Servers public key
If you haven't read my past asbout asymmetric encryption keys, feel free to explore the below
What is asymmetric encryption?
Locate the public and private keys
Analyse the output
During this stage , the server will send its public key to the client. The client verifies this key against the CA or list of known and trusted keys.
If using a CA, the servers public key is wrapped in a digital cert signed by the CA . This certificate confirms the authenticity of the servers public key.
This process is important to verify that the client is contacting the intended server and prevent miTm attack.
If the client has previously connected to the server and has the server's public key stored (in the ~/.ssh/known_hosts file), it will compare the received key with the stored one.
If the keys match, the connection proceeds without any warnings.
Lets look at the known_hosts file on the client device
Run the command to view the hosts file.
Derive a shared secret
The SSH protocol uses a key exchange algorithm to securely generate a shared secret. Common algorithms include Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH).
The client and server aggress on the key exchange method from previously exchanged list of supported algorithms . Then the client and server exchange the key exchange parameters e.h the public keys. The client and server then proceed to independently calculate their shared secret using their unique private kets and the received public values
Why do we need the shared secret?
Used to derive session keys for symmetric encryption which will encrypt the data transmitted during the SSH session.
These keys are never exchanged over the internet to ensure integrity.
Cipher Negotiation
The client and server agree on the encryption algorithm that is used to secure the communication between client and server.
During this stage, the client and server share their lists of supported ciphers. Both parties then compare the two lists to determine which ciphers are common. The client usually prioritises its cipher and selects the strongest cipher due to performance and security reasons
Client side supported ciphers
#ssh -Q cipher
user@annes-MacBook-Air ~ % ssh -Q cipher3des-cbcaes128-cbcaes192-cbcaes256-cbcaes128-ctraes192-ctraes256-ctrServer Side supported Ciphers
#sshd -T | grep ciphers
[root@localhost ~]# sshd -T | grep ciphers3des-cbcaes128-cbcaes192-cbcaes256-cbcaes128-ctraes192-ctraes256-ctrThe importance of this step is to ensure security and compatibility.
Message Authentication and compression Negotiation
Message Authentication ensures that the data exchanged between the client and server has not been altered during transmission and verifies the identity of the parties involved.
Authentication Algorithms: SSH supports various message authentication codes (MACs) that are used to verify the integrity and authenticity of the data. Common MAC algorithms include:
HMAC-SHA1: HMAC (Hash-based Message Authentication Code) combined with the SHA-1 hash function.
HMAC-SHA256: A more secure version using SHA-256.
HMAC-MD5: An older, less secure option that is generally discouraged
During the initial handshake, both the client and server exchange their lists of supported MAC algorithms. They then negotiate and agree on a common MAC to use for the session.
Compression Negotiation is the process of agreeing on whether to compress the data being transmitted and which compression algorithm to use.
Supported Compression Algorithms: Common compression methods supported in SSH include:
zlib: A widely used compression library that provides good compression ratios.
none: Indicates that no compression will be applied.
Session Encryption begins
Once the SSH connection establishment process has successfully completed the negotiation of ciphers, message authentication, and (optionally) compression, the next step is the initiation of session encryption. This step is crucial for ensuring that all data transmitted between the client and server is secure and confidential.
So, lets talk about the error.
This error occurs during the cipher negotiation step.
Solution
Add the missing cipher on the server side by modyfying the ssh config.d file
Create a new policy module
View the next article (Coming soon) which tests this case and walks through troubleshooting
In this blog, I’ve shared my thoughts on the various stages of establishing an SSH connection, including the importance of key exchange, cipher negotiation, message authentication, compression, and session encryption. Each of these steps plays a crucial role in ensuring secure and efficient communication between the client and server.
If you have any questions or would like to discuss further, please feel free to reach out to me! I'm here to help.
