When you clone a Linux server (whether through virtualization, cloud templates, or disk imaging), all cryptographic host keys get copied along with other system files. This creates identical SSH fingerprints across multiple machines, which poses security risks and causes warnings like:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
SSH host keys are typically stored in /etc/ssh/
with these common filenames:
/etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_rsa_key.pub /etc/ssh/ssh_host_ecdsa_key /etc/ssh/ssh_host_ecdsa_key.pub /etc/ssh/ssh_host_ed25519_key /etc/ssh/ssh_host_ed25519_key.pub
Here's the complete process to regenerate unique SSH host keys:
# Backup existing keys (optional but recommended) sudo mkdir /etc/ssh/backup_keys sudo mv /etc/ssh/ssh_host_* /etc/ssh/backup_keys/ # Generate new keys using ssh-keygen sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N "" sudo ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key -N "" sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N "" # Set proper permissions sudo chmod 600 /etc/ssh/ssh_host_*_key sudo chmod 644 /etc/ssh/ssh_host_*_key.pub # Restart SSH service sudo systemctl restart sshd
For cloud deployments or infrastructure-as-code setups, include this in provisioning scripts:
#!/bin/bash # Cloud-init example for AWS/GCP/Azure if [ ! -f /etc/ssh/ssh_host_ecdsa_key ]; then DEBIAN_FRONTEND=noninteractive dpkg-reconfigure openssh-server systemctl restart ssh fi
Check the new fingerprints with:
ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
Or remotely (before connecting):
ssh-keyscan -t rsa,ecdsa,ed25519 your.server.ip | ssh-keygen -lf -
After changing server keys, clients will see warnings until they update their ~/.ssh/known_hosts
file. To remove old entries:
ssh-keygen -R your.server.ip
When cloning or duplicating Linux servers (common in cloud environments or VM templates), you'll encounter SSH host key collisions because the cloned system retains the original server's keys. This manifests as scary warning messages:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Here's the proper way to regenerate all host key types on modern Linux distributions (tested on Ubuntu/Debian/CentOS/RHEL):
# Remove existing host keys
sudo rm /etc/ssh/ssh_host_*
# Regenerate all key types (RSA, ECDSA, Ed25519)
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""
sudo ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key -N ""
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
# Restart SSH service
sudo systemctl restart sshd # For systemd systems
# OR
sudo service ssh restart # For older init systems
Check the new fingerprints with:
ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
For clients, remove the old entry from ~/.ssh/known_hosts
or use:
ssh-keygen -R your.server.hostname
For infrastructure-as-code setups, include this in your provisioning scripts:
#!/bin/bash
# Cloud-init example for AWS/GCP/Azure
if [ ! -f /etc/ssh/ssh_host_rsa_key ]; then
ssh-keygen -q -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""
ssh-keygen -q -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key -N ""
ssh-keygen -q -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
systemctl restart sshd
fi
- Use at least 4096-bit RSA keys (2048 is deprecated)
- Ed25519 is now preferred over RSA/ECDSA
- Consider disabling weak key types in
/etc/ssh/sshd_config
:
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
# HostKey /etc/ssh/ssh_host_ecdsa_key # Disable if not needed