How to fix no hostkey alg in SSH

SSHINTERMEDIATEMEDIUMUpdated May 28, 2026· 849 views

The SSH "no hostkey alg" error occurs when the SSH client and server cannot agree on a compatible host key algorithm. This typically happens when newer clients connect to old servers whose only host key uses the deprecated ssh-rsa (SHA-1) algorithm.

Quick fix

Fixes no hostkey alg

ssh -vvv user@hostname 2>&1 | grep -i "host key algorithms"
  1. Check what host key algorithms client and server support
  2. Temporarily re-enable the legacy algorithm on the client (quick fix, not recommended)
  3. Enable modern algorithms on the server (recommended fix)
  4. Generate modern host keys on the server if missing
ssh — error
ssh -vvv user@hostname 2>&1 | grep -i "host key algorithms"
no hostkey alg

What this error means

When SSH establishes a connection, both the client and server exchange lists of supported algorithms for encryption, key exchange, and host key verification. The "no hostkey alg" error means there is no overlap between the client's accepted host key algorithms and the server's offered algorithms. This commonly occurs in two scenarios: 1. Newer OpenSSH clients connecting to old servers whose only host key is an RSA key, after OpenSSH 8.8 (released September 2021) disabled the SHA-1-based ssh-rsa algorithm by default. 2. Newer clients connecting to very old servers that don't support modern algorithms like ssh-ed25519 or ECDSA. The client refuses the connection rather than fall back to weaker, deprecated algorithms because OpenSSH 8.8 and later disable SHA-1-based algorithms (ssh-rsa) by default for security reasons.

Typical symptoms

  • SSH connection fails immediately during key exchange
  • Error appears before password or key authentication attempts
  • Connection works with one system but fails with another
  • Debug output shows algorithm mismatch when using ssh -vvv
  • rsync or git over SSH fails with this message

Common causes

  1. OpenSSH 8.8 or newer on the client disabled the ssh-rsa (SHA-1) host key algorithm by default
  2. Old SSH server only offers a single RSA host key and no modern ed25519/ECDSA key
  3. Server or client manually restricted HostKeyAlgorithms to exclude the needed options
  4. Cross-version compatibility issues (CentOS 6 -> CentOS 8, Amazon Linux 2 -> AL2023)
  5. SSH client configured with explicit HostKeyAlgorithms that don't overlap with the server

How to fix "no hostkey alg"

1Check what host key algorithms client and server support

Run verbose SSH and look for the host key algorithm negotiation lines:

bash
ssh -vvv user@hostname 2>&1 | grep -i "host key algorithms"

This surfaces the real debug line, debug2: host key algorithms:, showing the algorithms the client is willing to accept. You can also list everything your client supports independently of any connection:

bash
ssh -Q HostKeyAlgorithms

Compare these against what the server actually offers to find the specific mismatch.

2Temporarily re-enable the legacy algorithm on the client (quick fix, not recommended)

If the server only has an RSA host key, you can re-enable ssh-rsa for that connection. On OpenSSH 8.8+ you must allow it for both host key verification and public-key authentication:

bash
ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa user@hostname

The PubkeyAcceptedAlgorithms option is required because 8.8+ also disables ssh-rsa for key-based auth, so omitting it can leave authentication failing even after the host key is accepted.

Or add it to ~/.ssh/config for persistent use:

bash
Host specific-server
    Hostname 192.168.1.100
    User myuser
    HostKeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

The + prefix appends to the defaults instead of replacing them. This re-enables a deprecated SHA-1 algorithm, so treat it as a temporary measure only and prefer fixing the server.

3Enable modern algorithms on the server (recommended fix)

Edit /etc/ssh/sshd_config and set HostKeyAlgorithms to modern options:

bash
# Add strong modern algorithms
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256

Then restart sshd:

bash
sudo systemctl restart sshd
# or on some systems:
sudo service sshd restart

This keeps security intact while supporting modern clients. ssh-ed25519 and the rsa-sha2-* variants use secure hash algorithms.

4Generate modern host keys on the server if missing

Check which host keys exist:

bash
ls -la /etc/ssh/ssh_host_*

If the ed25519 or ecdsa keys are missing, generate them so the server can offer a non-SHA-1 host key:

bash
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
sudo ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key -N ""
sudo systemctl restart sshd

Modern clients prefer ed25519 for both security and performance, which permanently resolves the mismatch without any client-side workaround.

5Update a very old SSH client if needed

Check your SSH version:

bash
ssh -V

If you are on a very old OpenSSH (< 6.5) connecting to a modern server, update the client:

bash
# Ubuntu/Debian
sudo apt-get update && sudo apt-get install openssh-client

# macOS (via Homebrew)
brew install openssh

# CentOS/RHEL
sudo yum update openssh-clients

Older clients lack support for modern algorithms, so upgrading resolves this permanently.

Advanced notes

Algorithm reference:
- ssh-ed25519: Modern elliptic curve algorithm (fastest, most secure). Introduced in OpenSSH 6.5 (2013).
- rsa-sha2-512/256: RSA with SHA-2 hashing (secure). Requires OpenSSH 7.2+ (2016).
- ssh-rsa (deprecated): RSA with SHA-1 (legacy). Disabled by default in OpenSSH 8.8 (September 2021).
- ECDSA variants: Elliptic curve algorithms (ecdsa-sha2-nistp256/384/521). Middle-ground option for older systems.

On systems running in FIPS mode or under a crypto policy, some algorithms may be restricted regardless of sshd_config. List what your build actually supports with ssh -Q HostKeyAlgorithms.

On RHEL 8/9 and Amazon Linux 2023, system-wide crypto policies override sshd_config. Re-enabling ssh-rsa/SHA-1 there is done with update-crypto-policies (for example sudo update-crypto-policies --set DEFAULT:SHA1) rather than by editing sshd_config directly. Prefer adding a modern host key over weakening the policy.

Frequently asked questions

What does "no hostkey alg" mean?
When SSH establishes a connection, both the client and server exchange lists of supported algorithms for encryption, key exchange, and host key verification. The "no hostkey alg" error means there is no overlap between the client's accepted host key algorithms and the server's offered algorithms. This commonly occurs in two scenarios: 1.
How do I fix "no hostkey alg"?
The SSH "no hostkey alg" error occurs when the SSH client and server cannot agree on a compatible host key algorithm. This typically happens when newer clients connect to old servers whose only host key uses the deprecated ssh-rsa (SHA-1) algorithm.
What causes "no hostkey alg"?
OpenSSH 8.8 or newer on the client disabled the ssh-rsa (SHA-1) host key algorithm by default Old SSH server only offers a single RSA host key and no modern ed25519/ECDSA key Server or client manually restricted HostKeyAlgorithms to exclude the needed options
Is the "no hostkey alg" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading