Skip to content
DevOps AI ToolKit
Newsletter
All guides
AI for DevOps Security & Hardening By James Joyner IV · · 8 min read

SSHD Error: 'sshd: no hostkeys available -- exiting' — Cause, Fix, and Troubleshooting Guide

Quick answer

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
Free toolkit

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/sshd fails; the journal shows no hostkeys available -- exiting.
  • sshd -t reports 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_*_key files.
  • 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 failed and must update known_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 -R on /etc is a common trigger; keep host key perms exact.
Free download · 368-page PDF

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.