ssh-keygen -A generates these missing host keys for all supported key types, resolving the immediate connectivity issue and allowing standard SSH access to resume without manual intervention or complex configuration changes.
Understanding the Error Context
When an administrator attempts to connect to a Linux server via SSH, the server must present a unique host key to verify its identity. This process prevents man-in-the-middle attacks by ensuring the client is talking to the expected machine. If the directory containing these keys is empty, corrupted, or missing entirely, thesshd service will refuse to start or accept connections, logging the specific error regarding unavailable host keys.
This situation often arises after a fresh installation of an operating system where initialization scripts failed to complete, or after a system migration where configuration files were not properly transferred. It can also occur if disk space was exhausted during a previous update, preventing the creation of new key files. Recognizing this symptom is the first step toward restoring remote management capabilities.
Executing the Generation Command
The primary solution involves invoking thessh-keygen utility with the -A flag. This flag instructs the tool to automatically generate all host keys that are currently missing from the configured paths. The command operates non-interactively, meaning it does not require user input for passphrases or confirmation prompts, which makes it ideal for automated recovery scenarios or quick fixes on production servers.
To execute this, you must have root privileges because the host keys are stored in system directories accessible only to administrators. Open your terminal and run the following command:
sudo ssh-keygen -A/etc/ssh/, for existing keys. For every type (such as RSA, DSA, ECDSA, and ED25519) that is absent, it creates a new private and public key pair. You should see output indicating the generation of each key type. If the command completes without errors, the necessary files are now present on the filesystem.
Verifying Key Creation
After running the generation command, it is prudent to verify that the keys were created successfully before restarting services. You can list the contents of the/etc/ssh/ directory to confirm the presence of files ending in .pub (public keys) and their corresponding private counterparts. Common filenames include ssh_host_rsa_key, ssh_host_ecdsa_key, and ssh_host_ed25519_key.
If you do not see these files, check the permissions of the directory itself. The /etc/ssh/ directory must be owned by root and have restricted write permissions to ensure security. Incorrect permissions can prevent ssh-keygen from writing the new files even if the command appears to succeed.
Restarting the SSH Service
Generating the keys is only half the solution; the SSH daemon must be aware of their existence. Most modern Linux distributions use systemd to manage services. You need to restart thesshd service to load the newly generated keys into memory. Use the following command to restart the service:
sudo systemctl restart sshdservice sshd restart. After the restart, check the status of the service to ensure it is active and running without errors:
sudo systemctl status sshdSecurity Considerations and Alternatives
While generating default keys resolves the immediate outage, it is important to consider the strength of the algorithms used. Older systems might still rely on RSA keys with smaller bit lengths or DSA keys, which are considered weak by modern standards. If you have control over the key generation parameters, you may want to specify stronger options manually rather than relying on the defaults provided by-A.
For environments requiring high security, consider reviewing your SSH configuration file (/etc/ssh/sshd_config) to disable weaker protocols like SSHv1 or legacy key exchange methods. Additionally, if you frequently encounter this issue due to automated provisioning, integrating key generation into your deployment scripts ensures consistency across all new instances. For related issues involving connection failures, such as key exchange identification errors, refer to our guide on Troubleshooting kex_exchange_identification Error in Linux SSH Connection.
Frequently Asked Questions
Why does ssh-keygen -A fail with permission denied?
You likely do not have root privileges. The host keys are stored in /etc/ssh/, which requires administrative access to modify. Ensure you prefix the command with sudo or switch to the root user before executing.
Can I generate keys for only one specific algorithm?
No, the -A flag specifically targets all missing key types simultaneously. To generate a single type, you must invoke ssh-keygen without the -A flag and specify the desired key type explicitly using arguments like -t rsa or -t ed25519.
What happens if I delete my existing host keys?
Deleting the keys will cause the same "no host keys available" error upon the next SSH attempt. Clients will also receive a warning about the host key changing if you regenerate them later, potentially blocking automatic connections until the known_hosts file is updated.
Is it safe to use the default key sizes generated by this command?
Modern versions of ssh-keygen generate strong defaults, such as 2048-bit RSA or 256-bit Ed25519 keys, which are generally secure. However, if you are on an older system, verify the output to ensure it is not using deprecated algorithms like DSA.
How do I fix the error if ssh-keygen -A reports no missing keys?
If the command says no keys are missing but you still get the error, the issue may be with file permissions or ownership. Check that /etc/ssh/ files are owned by root and have restrictive permissions, typically 600 for private keys and 644 for public keys.