SSHD Error: 'sshd: no hostkeys available -- exiting' — Cause, Fix, and Troubleshooting Guide
Fix 'sshd: no hostkeys available -- exiting': missing/unreadable host keys, wrong HostKey paths, or bad permissions. Regenerate keys and restart sshd safely.
- #security
- #hardening
- #troubleshooting
- #linux
- #ssh
Fixing errors like this? Get 500 free DevOps AI prompts
500 copy-paste AI prompts for the stack you actually run — one PDF, free.
What this error means
The SSH daemon refuses to start because it cannot load any host key to identify itself to clients. Without at least one usable host key, sshd has no way to prove the server’s identity, so it exits immediately rather than run insecurely.
sshd: no hostkeys available -- exiting
error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
This is dangerous operationally: if it happens on a restart of a remote box, new SSH logins are impossible until you fix it via console/rescue access.
How it manifests on the host
systemctl start ssh/sshdfails; the journal showsno hostkeys available -- exiting.sshd -treports it cannot load host keys.- The host stopped accepting SSH after an image build, a
chmod -R, or a disk/partition issue. - Preceding
Could not load host key: ...lines name each missing/unreadable key.
System configuration causes
- Host keys missing. A minimal/base image or a botched cleanup removed
/etc/ssh/ssh_host_*_keyfiles. - Wrong permissions/ownership. Private host keys are group/world-readable or not owned by root, so sshd refuses them.
- HostKey paths point at nonexistent files in
sshd_config. - All configured key types disabled. Config references only key types whose files are absent.
- Read-only or unmounted /etc at start time.
Interrogating the host
# What does the daemon say when it tries to start?
sudo journalctl -u ssh --since '10 min ago' --no-pager | tail -20
sudo sshd -t # config + host key test
# Do the host key files exist with correct perms?
ls -l /etc/ssh/ssh_host_*_key /etc/ssh/ssh_host_*_key.pub
# Which HostKey paths does the config expect?
sudo sshd -T 2>/dev/null | grep -i hostkey
grep -i '^HostKey' /etc/ssh/sshd_config
Private keys must be 0600 (or 0640 root:ssh_keys on some distros) and owned by root; publics 0644.
Remediation
1. Regenerate the host keys if they are missing:
sudo ssh-keygen -A # creates all default host key types
sudo systemctl restart ssh
2. Fix permissions/ownership if the keys exist but are rejected:
sudo chown root:root /etc/ssh/ssh_host_*_key
sudo chmod 600 /etc/ssh/ssh_host_*_key
sudo chmod 644 /etc/ssh/ssh_host_*_key.pub
sudo systemctl restart ssh
3. Correct or generate a specific configured key if sshd_config names a missing path:
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ''
sudo sshd -t && sudo systemctl restart ssh
4. Validate before relying on it:
sudo sshd -t && echo "config + host keys OK"
Hardening the host
- Regenerating host keys changes the server’s fingerprint — clients will hit
Host key verification failedand must updateknown_hosts(verify the new fingerprint out-of-band). - On a remote host, fix this from a serial/rescue console; do not restart sshd blindly if you are unsure it will come back.
- Do not bake host keys into a shared image — every instance would share an identity; generate them at first boot (
ssh-keygen -A). - Overly strict
chmod -Ron/etcis a common trigger; keep host key perms exact.
Related system errors
- SSH ‘Host key verification failed’ Error Guide
- SSH ‘no matching host key type’ Error Guide
- Hardening SSH Access to Production Servers with AI
Get 500 Battle-Tested DevOps AI Prompts — Free
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.