How to regenerate SSH host keys

Regenerate SSH host keys when a server clone, rebuild, image template, or key exposure leaves the server identity untrustworthy. These keys identify the server before user authentication starts, so duplicated or compromised host keys can make clients trust the wrong machine or dismiss a real changed-key warning.

OpenSSH stores server host keys under /etc/ssh with names such as ssh_host_ed25519_key and matching .pub files. The ssh-keygen -A command creates the default RSA, ECDSA, and ED25519 host keys only when the files are missing, so existing keys must be moved aside before the command can replace them.

Rotating host keys changes what clients see during the SSH handshake. Keep console or out-of-band access open, record the new fingerprint from the server, restart sshd only after sshd -t returns cleanly, and tell clients to update known_hosts only after the new fingerprint has been verified through a trusted channel.

Steps to regenerate SSH host keys on a Linux server:

Open a root or sudo shell through the server console, hypervisor console, or another access path that will not depend on the next SSH login.

Regenerated host keys will trigger changed-key warnings for existing clients. Do not remove client known_hosts entries until the new fingerprint is verified.
Create a protected backup directory for the current host keys.
```
$ sudo install -d -m 700 /root/ssh-host-key-backup
```
Move the existing host key files into the backup directory.
```
$ sudo mv /etc/ssh/ssh_host_* /root/ssh-host-key-backup/
```
If the server has no matching files, continue with the generation step. Host certificates tied to the old key need to be replaced before certificate-based trust works again.
Related: How to configure SSH host certificates

Generate new default OpenSSH host keys.

$ sudo ssh-keygen -A
ssh-keygen: generating new host keys: RSA ECDSA ED25519

List the regenerated public host key files.

$ sudo ls /etc/ssh/ssh_host_*_key.pub
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key.pub

Print the new ED25519 host key fingerprint on the server.
```
$ sudo ssh-keygen -l -E sha256 -f /etc/ssh/ssh_host_ed25519_key.pub
256 SHA256:FXelDYqHPmYeXeSa7zNbhS7RDcyCwQXJSv8EsP+jtbU root@host (ED25519)
```
Record the SHA256 fingerprint in a trusted ticket, inventory record, or console log before asking clients to trust the rotated key.
Test the sshd configuration and host key sanity.
```
$ sudo sshd -t
```
No output means the daemon parsed the configuration and accepted the regenerated host keys.
Related: How to test SSH server configuration
Restart the SSH server service to load the new host keys.
```
$ sudo systemctl restart ssh
```
Use sudo systemctl restart sshd on systems where the service unit is sshd.
Related: How to manage the SSH server service with systemctl
Confirm that the SSH service is active after the restart.
```
$ sudo systemctl is-active ssh
active
```
If the unit is not active, use the console session to inspect the journal before closing any working access path.
Scan the presented ED25519 host key from a client or bastion host.
```
$ ssh-keyscan -t ed25519 host.example.net > host.example.net.pub
```
ssh-keyscan collects the public key without adding it to known_hosts.
Compare the scanned host key fingerprint with the server-side fingerprint.
```
$ ssh-keygen -l -E sha256 -f host.example.net.pub
256 SHA256:FXelDYqHPmYeXeSa7zNbhS7RDcyCwQXJSv8EsP+jtbU host.example.net (ED25519)
```
Stop if the fingerprint differs from the trusted server value, because the client may be reaching the wrong host or an unexpected key.
Related: How to verify SSH host key fingerprints before connecting
Tool: Secure Shell (SSH) Key Fingerprint Checker
Remove the temporary scanned public key file.
```
$ rm host.example.net.pub
```
Update client trust records only after the new fingerprint is confirmed.

Use the changed-key warning workflow for existing clients that still have the old host key saved.
Related: How to fix the SSH remote host identification has changed warning