This warning appears when SSH connects to a server for the first time (or after the server's host key changes) and stores the host's public key fingerprint in your known_hosts file. It's an informational message, not an error, but indicates that SSH is learning a new host identity for future verification.
SSH uses a "trust on first use" security model: when you connect to a new SSH server, the server presents its public key (host key). SSH doesn't have a pre-established trust relationship, so it stores the key's fingerprint (a short hash) in your ~/.ssh/known_hosts file. On future connections, SSH verifies that the server's key hasn't changed, protecting you from man-in-the-middle attacks. This warning message means SSH has successfully completed this process—it's adding the host to your known_hosts and confirming the key type (in this case, ECDSA, an elliptic-curve algorithm). The warning is actually a security feature working as intended.
The warning message is completely normal and expected behavior. SSH is designed to:
1. Connect to the server and retrieve its public key
2. Calculate the fingerprint (SHA256 hash)
3. Store it in ~/.ssh/known_hosts
4. Use this fingerprint on future connections to verify the server hasn't been compromised
You can safely continue—the connection is secure.
For sensitive servers, confirm the fingerprint through an independent trusted channel (phone call, secure email, console access) before accepting. When prompted, SSH shows the fingerprint:
The authenticity of host 'example.com (192.168.1.100)' can't be established.
ECDSA key fingerprint is SHA256:aBcDeF1234567890.
Are you sure you want to continue connecting (yes/no/[fingerprint])?Compare this fingerprint against your server administrator's documented value. If they match, type yes to accept.
When SSH prompts for the first time, answer yes to accept the host key:
ssh [email protected]
# First connection prompt appears
# Are you sure you want to continue connecting (yes/no)? yesSSH will then display:
Warning: Permanently added 'example.com' (ECDSA) to the list of known hosts.After this, the warning disappears on subsequent connections to the same host.
After accepting a host key, you can view it in your known_hosts file:
cat ~/.ssh/known_hosts | grep example.comOutput will look similar to:
example.com,192.168.1.100 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBG...This shows the hostname, key type (ECDSA), and the public key data.
If you need to automate SSH connections without interactive prompts, pre-populate known_hosts using ssh-keyscan:
ssh-keyscan example.com >> ~/.ssh/known_hostsThis adds the host key without prompting, useful in CI/CD pipelines or scripts. For multiple hosts:
ssh-keyscan -f host_list.txt >> ~/.ssh/known_hostsThe -H flag hashes the hostname for privacy:
ssh-keyscan -H example.com >> ~/.ssh/known_hostsIf you want to suppress this informational message in scripts, adjust the SSH LogLevel:
ssh -o LogLevel=ERROR [email protected]Or add to your SSH config (~/.ssh/config):
Host example.com
LogLevel ERRORNote: Suppressing the message doesn't disable security—SSH still verifies the key. It just hides the informational output.
For all hosts:
Host *
LogLevel ERRORHowever, keeping LogLevel at default (INFO) is recommended during development so you see host key changes, which could indicate a security issue.
If the warning keeps appearing for the same host (instead of disappearing after the first connection), the host key has changed. This warrants investigation:
ssh [email protected]
# ERROR: REMOTE HOST IDENTIFICATION HAS CHANGED!
# This could indicate a man-in-the-middle attack or server key rotationSteps to resolve:
1. Contact the server admin - Ask if the SSH key was intentionally rotated
2. Remove the old key from known_hosts:
ssh-keygen -R example.com3. Get the new fingerprint from the admin via trusted channel
4. Reconnect and verify the new fingerprint matches
5. Accept the new key when prompted
Never force-accept a changed host key without verification—this defeats SSH's security.
Advanced topics:
ECDSA vs RSA vs ED25519: Modern SSH servers support multiple host key algorithms. ECDSA (elliptic-curve) keys are smaller but RSA and ED25519 are more widely supported. The key type shown in the warning (ECDSA, RSA, or ED25519) depends on the server's SSH configuration. If a server regenerates its key with a different algorithm, you'll see a different key type in the warning message.
HashKnownHosts: Some systems enable HashKnownHosts yes in SSH config, which hashes the hostnames in known_hosts for privacy. If enabled, the hosts won't be human-readable:
|1|aBcDeF1234...= |2|xYzAbC5678...=This prevents attackers from reading the file to see which hosts you've connected to, but makes manual editing difficult.
SSHFP DNS Records: Modern deployments use SSHFP (SSH Fingerprint) DNS records to publish host keys. SSH can verify keys automatically via DNS queries, reducing reliance on manual fingerprint verification. Enable with:
ssh -o VerifyHostKeyDNS=yes [email protected]Persistent Connections: Some SSH multiplexing configurations (ControlMaster auto) reuse connections, so you only see the warning once per session, not per command.
CI/CD Pipelines: In automated environments, always use ssh-keyscan to pre-populate known_hosts before running SSH commands, or set StrictHostKeyChecking=accept-new with caution (only accepts new keys, rejects changed keys).
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
Load key "/home/user/.ssh/id_rsa": invalid format
How to fix 'Load key invalid format' in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH