Fix SSH No Hostkeys Available Exiting Error (2026)

The SSH client failed because it couldn’t find any host keys to verify the server’s identity, leading to an immediate exit to prevent a potential man-in-the-middle attack.

Cause 1: Missing known_hosts File

The most common reason is that the ~/.ssh/known_hosts file, where SSH stores verified host keys, either doesn’t exist or is empty. SSH requires this file to exist, even if it contains no entries, to function correctly.

• Diagnosis: Check for the existence of the file:

  ls -l ~/.ssh/known_hosts
  

  If it’s not found or ls shows it’s empty (0 bytes), this is your problem.

• Fix: Create the file if it doesn’t exist, or ensure it has at least one line if it’s empty. A common way to ensure it exists and is properly permissioned is to run ssh-keyscan:

  mkdir -p ~/.ssh
  touch ~/.ssh/known_hosts
  chmod 600 ~/.ssh/known_hosts
  ssh-keyscan your_server_hostname_or_ip >> ~/.ssh/known_hosts
  

  This creates the directory and file, sets the correct permissions (only the owner can read/write), and then adds the server’s host key to the file.

• Why it works: SSH checks for the presence of ~/.ssh/known_hosts. If it’s missing, it doesn’t know where to store or find keys. Creating it and adding the server’s key establishes the necessary trust relationship for the client to proceed.

Cause 2: Incorrect Permissions on ~/.ssh Directory

If the ~/.ssh directory itself has permissions that are too broad (e.g., world-writable), SSH will refuse to use it for security reasons, even if known_hosts exists.

• Diagnosis: Check the permissions of the .ssh directory:

  ls -ld ~/.ssh
  

  Look for any w flags for "other" users (e.g., drwxr-xr-x is fine, but drwxrwxrwx or drwxr-xrw- is not).

• Fix: Set the permissions to 700 (owner read, write, execute only):

  chmod 700 ~/.ssh
  

• Why it works: SSH strictly enforces that the ~/.ssh directory must only be modifiable by the user. This prevents other users on the system from injecting malicious keys into your known_hosts file.

Cause 3: Incorrect Permissions on known_hosts File

Similar to the directory, if the known_hosts file has overly permissive read or write access, SSH will reject it.

• Diagnosis: Check the permissions of the known_hosts file:

  ls -l ~/.ssh/known_hosts
  

  Look for any w or r flags for "group" or "other" users (e.g., -rw-rw-r-- is bad, -rw------- is good).

• Fix: Set the permissions to 600 (owner read, write only):

  chmod 600 ~/.ssh/known_hosts
  

• Why it works: SSH requires that only the owner can read or write to known_hosts. This is to prevent other users from altering the list of trusted keys, which could allow them to impersonate servers.

Cause 4: Corrupted known_hosts File

Sometimes, the known_hosts file can become corrupted due to incomplete writes, manual editing errors, or other system issues. This can manifest as a "No Hostkeys Available" error or other cryptic messages.

• Diagnosis: While hard to definitively diagnose programmatically without parsing, a large, seemingly random file or one with unusual characters might be suspect. A quick test is to temporarily rename it.

• Fix: Rename the existing known_hosts file and let SSH recreate it on the next connection.

  mv ~/.ssh/known_hosts ~/.ssh/known_hosts.bak
  ssh your_server_hostname_or_ip
  

  When prompted to accept the new host key, type yes.

• Why it works: By renaming the file, you effectively start with a clean slate. SSH will prompt you to verify and accept the server’s host key again, and a new, valid known_hosts file will be created.

Cause 5: SSH Client Configuration (ssh_config)

Although less common for this specific error, a misconfigured ssh_config file could theoretically interfere with host key management. For instance, if StrictHostKeyChecking is set to no but other configurations prevent key loading.

• Diagnosis: Examine your SSH client configuration file, typically located at /etc/ssh/ssh_config and ~/.ssh/config. Look for lines related to HostKeyAlias, HostKeyRepository, or StrictHostKeyChecking.

• Fix: Temporarily comment out or remove any unusual configurations in your ~/.ssh/config file that might affect host key handling. For troubleshooting, you can try connecting with a minimal configuration by running:

  ssh -F /dev/null your_server_hostname_or_ip
  

  If this works, you know your ~/.ssh/config is the culprit.

• Why it works: The -F /dev/null option tells SSH to ignore all configuration files, forcing it to use its default settings and preventing any user-specific configurations from interfering with the host key lookup process.

Cause 6: System-Wide SSH Configuration (sshd_config on Server)

While the error is on the client, a server-side misconfiguration could indirectly cause issues if the client is unable to retrieve the host key in the first place, though this is rare for "No Hostkeys Available." More likely, this would manifest as a server-side error. However, if the server is configured not to send its host key for some reason (highly unlikely and insecure), the client would have nothing to store.

• Diagnosis: Check the server’s /etc/ssh/sshd_config file for directives like HostKey. Ensure it points to a valid file and that the server process has read permissions.

• Fix: On the server, ensure the HostKey directive in /etc/ssh/sshd_config is uncommented and points to the correct key file (e.g., /etc/ssh/ssh_host_rsa_key). Restart the SSH daemon:

  sudo systemctl restart sshd
  

• Why it works: This ensures the SSH server is properly configured to use its own host keys, which the client then retrieves and stores.

After fixing these, the next error you might encounter is related to authentication failures if your user credentials are still incorrect.