The SSH daemon (sshd) cannot start because it cannot find or access its host keys. Host keys are cryptographic credentials that identify the SSH server to clients, and they must exist and be accessible for sshd to operate. This error typically occurs after a fresh installation, accidental deletion, or permission changes that prevent sshd from reading the keys.
SSH host keys are essential cryptographic files stored on your server (usually in /etc/ssh/) that allow the SSH daemon to identify itself to connecting clients and establish encrypted connections. When sshd starts, it immediately looks for these host keys in the locations specified by its configuration file (sshd_config). If no host keys exist at the configured paths or if the files are not readable due to permission issues, sshd exits with this error rather than starting with inadequate security. This prevents insecure SSH connections and protects against potential security misconfigurations.
First, verify whether the host key files actually exist on your system:
ls -la /etc/ssh/ssh_host_*key*You should see output like:
- ssh_host_rsa_key (private, mode 600)
- ssh_host_ecdsa_key (private, mode 600)
- ssh_host_ed25519_key (private, mode 600)
- ssh_host_*_key.pub files (public, mode 644)
If these files don't exist at all, proceed to Step 2. If they exist but show wrong permissions, skip to Step 3.
If the host key files don't exist, generate them using ssh-keygen:
Option A: Generate all default keys at once (recommended)
sudo ssh-keygen -AThis command automatically generates all missing key types (RSA, ECDSA, ED25519) in their standard locations.
Option B: Generate individual key types manually
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""
sudo ssh-keygen -t ecdsa -b 256 -f /etc/ssh/ssh_host_ecdsa_key -N ""
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""The -N "" flag means "no passphrase" (required for host keys).
After generation, verify the files exist:
ls -la /etc/ssh/ssh_host_*key*Host key permissions must be:
- Private keys (ssh_host_*_key): 600 (readable only by root)
- Public keys (ssh_host_*_key.pub): 644 (world-readable)
Fix permissions with:
sudo chmod 600 /etc/ssh/ssh_host_*_key
sudo chmod 644 /etc/ssh/ssh_host_*_key.pubVerify the result:
ls -la /etc/ssh/ssh_host_*Private keys should show -rw------- (600) and public keys -rw-r--r-- (644).
Ensure ownership is correct (should be root):
sudo chown root:root /etc/ssh/ssh_host_*Open your SSH configuration file and verify the HostKey directives point to the correct locations:
sudo grep -n "^HostKey" /etc/ssh/sshd_configYou should see entries like:
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_keyIf these lines are missing or commented out (start with #), add or uncomment them:
sudo nano /etc/ssh/sshd_configEnsure these lines are present and uncommented:
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_keySave and exit (Ctrl+O, Enter, Ctrl+X in nano).
After generating keys and fixing permissions, restart the SSH daemon:
On systemd systems (most modern Linux):
sudo systemctl restart sshdVerify it's running:
sudo systemctl status sshdOn older init systems:
sudo service ssh restartCheck for errors in logs:
sudo journalctl -xe -u sshd | tail -20If you see "sshd: no hostkeys available" still, check the previous steps. If you see a different error, record that error message for further troubleshooting.
Verify SSH is now working:
ssh -v localhostOr from another machine:
ssh username@your-server-ipIf connection succeeds, the issue is resolved. If you get a different error (e.g., "Connection refused"), the host keys are working but another issue exists (firewall, port binding, etc.).
On Debian/Ubuntu systems, you can use dpkg to regenerate SSH keys:
sudo rm /etc/ssh/ssh_host_*
sudo dpkg-reconfigure openssh-serverThis removes the old keys and lets the openssh-server package regenerate them during reconfiguration. It's safe to run over an existing SSH session—your current connection won't be interrupted.
After reconfiguration, check that new keys were generated:
ls -la /etc/ssh/ssh_host_*key*Advanced troubleshooting:
Containerized deployments: When building Docker images or VMs, SSH host keys should be generated during image creation or at first boot (not committed to the image itself, as each instance needs unique keys). Use an entrypoint script:
#!/bin/bash
if [ ! -f /etc/ssh/ssh_host_rsa_key ]; then
ssh-keygen -A
fi
exec /usr/sbin/sshd -DCloud provider gotchas: AWS, Azure, and GCP run initialization scripts that generate host keys automatically on first boot. If you see this error on a cloud instance, the initialization script may have failed. Check cloud-init logs:
cloud-init status
cat /var/log/cloud-init-output.logSELinux/AppArmor issues: On systems with mandatory access controls, wrong SELinux contexts or AppArmor profiles can prevent sshd from accessing key files even if permissions look correct. Check:
# SELinux systems
getenforce
restorecon -Rv /etc/ssh/
# AppArmor systems
sudo systemctl status apparmorFilesystem issues: If /etc/ssh/ is on a read-only mounted filesystem or network mount with caching issues, sshd cannot read keys. Verify:
mount | grep "/etc/ssh"
touch /etc/ssh/.test_write # Try writing a test fileDebugging with verbose sshd: Run sshd in debug mode to see exactly which paths it's looking for:
sudo /usr/sbin/sshd -ddd # (don't do this on production while listening on port 22)Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
Load key "/home/user/.ssh/id_rsa": invalid format
How to fix 'Load key invalid format' in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH