Understanding KEX Algorithms in sshd_config: Does 'pseudo' Override or Take Effect?

The term 'pseudo' does not exist as a valid KexAlgorithms value or directive in OpenSSH sshd_config. It is likely a confusion with the legacy SSH-1 protocol, which used a "pseudorandom" key exchange method that is now obsolete and disabled by default. Modern SSH configurations should rely on established algorithms like curve25519-sha256 or diffie-hellman-group-exchange-sha256.

Clarifying the Misconception About 'Pseudo'

When administrators encounter the word "pseudo" in the context of SSH Key Exchange (KEX), they are often referring to historical documentation or misinterpreting internal code comments. In the early days of SSH, specifically version 1, the key exchange mechanism was indeed based on pseudorandom number generation techniques to establish shared secrets. However, SSH-1 has been deprecated for nearly two decades due to significant security vulnerabilities, including susceptibility to man-in-the-middle attacks. OpenSSH, the standard implementation for Linux and Unix-like systems, removed support for SSH-1 long ago. Consequently, there is no configuration option named KexAlgorithms pseudo or any variant thereof. If you attempt to set this value in your /etc/ssh/sshd_config, the SSH daemon will fail to start or ignore the invalid entry, logging an error indicating that the specified algorithm is unknown. This behavior confirms that 'pseudo' is not a recognized token in the modern cryptographic suite. It is crucial to distinguish between the concept of pseudorandomness, which is fundamental to all secure cryptography, and actual algorithm names. All modern key exchange methods use pseudorandom functions internally, but they are identified by specific IANA-standardized strings. Administrators must configure these exact strings to ensure compatibility and security.

Valid KexAlgorithms Configurations

To properly configure key exchange algorithms, you must use the official list provided by the OpenSSH project. These algorithms determine how the client and server negotiate a shared secret before encrypting the session. The most common and recommended algorithms include:

• curve25519-sha256: A modern elliptic curve Diffie-Hellman exchange that offers high performance and strong security.
• [email protected]: An older identifier for the same curve25519 implementation, sometimes seen in older clients.
• diffie-hellman-group-exchange-sha256: Allows the server to generate a custom-sized DH group, providing flexibility and strength.
• diffie-hellman-group14-sha256: A widely supported standard DH exchange using 2048-bit groups.

You can view the full list of supported algorithms on your specific system by running ssh -Q kex as root. This command outputs every key exchange method currently compiled into your OpenSSH binary. Using this output ensures that your configuration matches what the software actually supports. When editing sshd_config, you specify these algorithms in the KexAlgorithms directive. For example:

KexAlgorithms curve25519-sha256,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256

This configuration prioritizes the fastest and most secure options first. The server will propose these in order until the client accepts one. If a client only supports older algorithms, the connection may fail if those are not included in the list. Always test changes with sshd -t before restarting the service to avoid locking yourself out.

Security Implications of Algorithm Selection

Choosing the right KEX algorithms directly impacts your server's resistance to cryptanalytic attacks. Weak algorithms like diffie-hellman-group1-sha1 rely on small key sizes and hash functions that are no longer considered secure against determined attackers. Disabling these weak options forces connections to use stronger cryptographic primitives. Furthermore, ensuring that your server supports curve25519 variants helps future-proof your infrastructure. As computational power increases, older DH groups become vulnerable to brute-force attacks via pre-computation tables. Elliptic curve methods provide equivalent security with much smaller key sizes, making them more efficient and harder to break. For users managing large fleets of servers, consistent algorithm configuration is vital. You can automate this using tools like Ansible or Puppet to enforce strict KEX policies across your environment. Regular audits of sshd_config help identify any lingering references to deprecated protocols or algorithms that might have been accidentally re-enabled.

Troubleshooting Connection Failures

If you experience connection failures after modifying KexAlgorithms, the issue is almost always a mismatch between server and client capabilities. Clients such as older versions of PuTTY, OpenSSH on legacy operating systems, or embedded IoT devices may not support modern algorithms like curve25519. To diagnose this, enable verbose logging on the client side using ssh -v user@host. Look for lines starting with kex_exchange_identification or No matching key exchange method found. This message explicitly states that the server and client could not agree on a common algorithm. In such cases, you must either update the client software to support modern standards or add legacy algorithms to your server's KexAlgorithms list. However, adding legacy algorithms reduces overall security. It is generally better to upgrade clients than to weaken server security. Remember that changing configuration requires reloading the SSH service, typically via systemctl reload sshd. For more information on securing SSH keys, see Understanding Different Hash Values in SSH-Keygen SHA256. Additionally, understanding how to restrict access based on groups can complement your cryptographic hardening efforts, as detailed in Restricting SSH Access for wheel Group Users in Red Hat 9 using PAM's pam_access.so - Not Denying Access.

Frequently Asked Questions

Why did my SSH config reject 'pseudo'?

The OpenSSH daemon does not recognize 'pseudo' as a valid key exchange algorithm name. It is not a real directive or value in sshd_config. Using it causes a syntax error or an invalid parameter warning because the software expects standardized algorithm identifiers.

Is SSH-1 still supported in modern Linux distributions?

No, SSH-1 is completely unsupported in current versions of OpenSSH. It was removed due to critical security flaws that allow attackers to intercept communications. Any reference to SSH-1 features is outdated and should be avoided in new configurations.

How do I check which KEX algorithms my server supports?

Run the command ssh -Q kex as the root user. This lists all key exchange methods compiled into the installed OpenSSH binary. You can then select from this list to populate your KexAlgorithms configuration line.

What happens if I disable all modern KEX algorithms?

Modern clients will fail to connect because they require strong cryptographic exchanges. Only very old, insecure clients might succeed if you force them to use deprecated methods. This creates a significant security risk and is strongly discouraged for production environments.

Can I mix different types of KEX algorithms in one config?

Yes, you can list multiple algorithms separated by commas. The server will try them in the order listed, preferring the first ones. This allows you to support both modern and slightly older clients while prioritizing security.