SSH protects remote access to Linux servers, cloud machines, and network devices. Most administrators already use SSH keys to authenticate users and verify server identities. The algorithms behind those keys matter because future advances in quantum computing could weaken some widely used public-key cryptography.
OpenSSH 10.6 adds support for the hybrid signature algorithm ssh-mldsa44-ed25519. It combines ML-DSA-44, a post-quantum digital signature algorithm, with Ed25519, an established signature algorithm.
For server administrators, the main task is to understand how the new algorithm works, confirm which systems support it, and test authentication before changing production SSH configurations.
What Are Post-Quantum SSH Signatures?
Traditional public-key algorithms such as RSA and Ed25519 rely on mathematical problems that sufficiently capable quantum computers could solve more efficiently than classical computers.
ML-DSA is a digital signature algorithm designed to resist attacks from quantum computers. It was standardized by the US National Institute of Standards and Technology as part of its post-quantum cryptography work.
OpenSSH 10.6 introduces the hybrid signature algorithm ssh-mldsa44-ed25519. The hybrid approach combines a post-quantum signature with Ed25519, allowing SSH to use both cryptographic components when the algorithm is negotiated and supported.
It is important to distinguish signatures from key exchange. SSH signatures help establish authenticity, such as verifying a server's host key or authenticating a user. Key exchange establishes shared session secrets used to protect the connection.
OpenSSH already supports post-quantum key exchange. The signature change addresses a different part of SSH security.
What Changed in OpenSSH 10.6?
The release enables the hybrid post-quantum signature algorithm for SSH.
One detail matters when upgrading. The new algorithm name no longer includes the @openssh.com vendor extension suffix used by the previous experimental implementation. Keys generated with that experimental support must be regenerated or removed.
Administrators should review their SSH configurations and key inventories before upgrading.
Area | What administrators should check |
|---|
SSH clients | Whether the installed client supports the new signature algorithm |
SSH servers | Whether the server can negotiate the algorithm with compatible clients |
Host keys | Whether the correct key files exist and are configured |
User authentication | Whether public-key login works with the intended key type |
Automation | Whether deployment scripts and management tools support the new algorithm |
Rollback | Whether an existing, supported authentication method remains available |
Do not assume that upgrading the server automatically upgrades every client. Older operating systems, embedded devices, and third-party SSH implementations may have different capabilities.
1. Check the Installed OpenSSH Version
Start by checking the SSH client and server versions.
On Linux, run:
ssh -V
For the SSH server, the command depends on the operating system and package manager. On a system using systemd, you can check the service status with:
sudo systemctl status sshd
Some distributions name the service ssh instead of sshd.
The version string helps establish which implementation you are using, but it does not prove that every required algorithm is enabled. Distribution packages may also include backported changes.
Check the available signature algorithms:
ssh -Q key-sig
To filter the output on Linux or macOS:
ssh -Q key-sig | grep -i mldsa
On Windows, you can use findstr instead of grep:
ssh -Q key-sig | findstr /i mldsa
If the algorithm does not appear, check the installed OpenSSH version and package build before changing the server configuration.
2. Generate a Test Key
Use a staging server to test the new algorithm before changing a production host.
With an OpenSSH build that supports the algorithm, generate a test key:
ssh-keygen -t ssh-mldsa44-ed25519 -f ~/.ssh/id_mldsa_test
Choose a passphrase when prompted if the key will be stored on a developer workstation.
This command uses a separate filename so the test key does not overwrite an existing SSH key. The exact command must be supported by the installed ssh-keygen implementation.
Check the generated files:
ls -l ~/.ssh/id_mldsa_test*
The private key should be kept secret. The .pub file contains the public key, which can be installed on the test server for user authentication.
Do not replace existing host keys or production user keys simply to try the new algorithm. Keep the test separate until compatibility has been confirmed.
3. Test SSH Authentication
For user authentication, install the test public key on the staging server using an administrator-approved process. If the server supports the new key type, try connecting with the test identity.
ssh -i ~/.ssh/id_mldsa_test \
-o IdentitiesOnly=yes \
testuser@staging-server
Replace testuser and staging-server with the actual account and hostname.
The -i option selects the private key. IdentitiesOnly=yes tells the client to use the configured identity rather than trying every key offered by the agent.
If the connection fails, enable verbose logging:
ssh -vvv -i ~/.ssh/id_mldsa_test \
-o IdentitiesOnly=yes \
testuser@staging-server
Look for messages about supported algorithms, authentication attempts, and rejected keys. These details can help distinguish an algorithm negotiation problem from an incorrect username, missing public key, or server access policy.
A successful login confirms that the tested client, server, key, and configuration work together. It does not prove that every SSH client in the organization is compatible.
4. Check Server Host-Key Compatibility
SSH host keys help clients verify that they are connecting to the expected server. User authentication keys serve a different purpose.
Before introducing a new host-key type, review the server's existing configuration. The relevant directive is HostKey in sshd_config.
For example, an administrator might have entries such as:
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
These are examples of existing host-key entries, not instructions to replace them with a new key path. A new host key must first be generated using a compatible OpenSSH build, stored with appropriate permissions, and configured correctly.
Keep a known-good host-key option available while testing. Confirm that clients can verify the server identity and that the server presents a compatible key during negotiation.
For configuration changes, validate the server configuration before reloading the service:
sudo sshd -t
If validation succeeds, follow the operating system's service-management procedure to apply the change. Keep an active administrative session open until a new connection has been tested successfully.
5. Understand the Security Benefits and Limits
Post-quantum signatures help prepare SSH authentication for a future in which quantum computers could threaten traditional public-key signature algorithms.
The hybrid design combines ML-DSA-44 with Ed25519. This provides a migration path that retains a conventional signature component alongside a post-quantum component.
There are limits to what this change accomplishes. A post-quantum signature does not automatically make every part of an SSH connection post-quantum secure. The negotiated key-exchange algorithm, encryption algorithms, host-key policy, client implementation, and operational practices still matter.
Signature migration also addresses a different risk from the practice of recording encrypted traffic today and attempting to decrypt it later. That concern primarily involves key exchange and the protection of recorded session data.
Administrators should therefore review signature and key-exchange policies separately.
Common Mistakes to Avoid
Replacing existing keys immediately
Do not remove working keys before confirming that the replacement works across required clients. Keep the change reversible until testing is complete.
Assuming the server controls client support
The server cannot make an older client support an algorithm it does not implement. Check the clients used by administrators, deployment tools, monitoring systems, and automation.
Treating a successful connection as complete validation
Test host-key verification, user authentication, reconnects, automation, and recovery procedures. Different workflows may use different keys and configuration rules.
Ignoring the previous experimental key format
OpenSSH 10.6 changes the algorithm name compared with the earlier experimental implementation. Review existing test keys and regenerate or remove obsolete experimental keys as required.
Best Practices for Server Administrators
Inventory SSH clients, servers, host keys, and user authentication keys.
Test OpenSSH 10.6 in a staging environment before changing production.
Verify algorithm availability with ssh -Q key-sig.
Keep private keys protected and use separate filenames for test keys.
Test both host-key verification and user authentication.
Review the negotiated algorithms using verbose client logs.
Keep a working administrative session open during server changes.
Maintain a tested rollback procedure and document compatibility issues.
Advantages and Disadvantages
Advantages | Disadvantages |
|---|
Adds a post-quantum component to SSH signatures | Requires compatible clients and servers |
Combines ML-DSA-44 with Ed25519 | May require key regeneration for previous experimental keys |
Supports gradual testing before wider adoption | Requires changes to key inventories and operational procedures |
Helps prepare authentication systems for future cryptographic risks | Does not make every SSH algorithm post-quantum secure |
Troubleshooting Common Problems
If the algorithm is missing from ssh -Q key-sig, verify the installed OpenSSH build and package version.
If key generation fails, confirm that the installed ssh-keygen supports the requested key type. Do not assume that every package carrying the same major version has identical capabilities.
If authentication fails, inspect the verbose SSH output, confirm that the public key is installed for the correct user, and check the server's authentication policy.
If a configuration change prevents new connections, use the existing administrative session to restore the previous working configuration. Avoid closing that session until the new setup has been verified.
Summary
OpenSSH 10.6 adds the hybrid post-quantum signature algorithm ssh-mldsa44-ed25519, combining ML-DSA-44 with Ed25519. This gives administrators a new option for preparing SSH authentication for post-quantum cryptography.
Start by checking algorithm support, generating a separate test key, and validating authentication on a staging server. Review host-key handling and automation before making wider changes.
The safest migration is a controlled one. Preserve working access methods, test every important client and workflow, and introduce the new algorithm only after compatibility and recovery procedures have been confirmed.
Join the conversation! Your thoughts help the community grow.