Dennis HilkLinux Fix LabDE

SSH, Security & Permissions

SSH reports a changed server host key

A host-key warning can follow a rebuild or a wrong destination. Verify the new fingerprint independently before editing known_hosts.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • SSH stops before account authentication.
  • A known_hosts line is identified as conflicting.

Relevant environment

OpenSSH client; inspect local known_hosts and a trusted console on the intended server.

Recognizable messages (synthetic examples)
@@@@@@@@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@@@@@@@

Treat this as an identity check, not an invitation to bypass verification.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • The server may have legitimately regenerated its host key.
  • DNS, a reused IP address or interception may lead to another host.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Replace HOSTNAME with the exact SSH destination; use [HOSTNAME]:PORT for a nondefault port. Searches hashed entries too.

ssh-keygen -F HOSTNAME

Interpret the result: The reported lines show which stored identity conflicts; no result may mean HostKeyAlias or another known_hosts file is in use.

Check 2

Run at the intended server through an independently trusted console. Use the actual public host-key path and algorithm.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Interpret the result: Compare the SHA256 fingerprint with the changed key reported by SSH. A network ssh-keyscan result alone cannot establish trust.

Evidence-guided next steps

Replace only an independently verified entry

After confirming a legitimate key change and destination, back up known_hosts and remove the exact host entry with ssh-keygen -R HOSTNAME, including its port when applicable. Reconnect and compare the offered fingerprint with the trusted console before accepting.

Precautions: Do not clear the entire file or set StrictHostKeyChecking=no. A rebuild is an explanation only after verification.

Recovery / rollback: Restore the backup to restore the previous trust decision; expect the warning to return if the server still presents the new key.

Did this solution help you?

Share this solution#

Correct a wrong destination or alias

If the independently checked fingerprint differs, stop the connection. Inspect the destination, port, HostName and HostKeyAlias in the host-specific SSH configuration; correct a stale DNS record or alias through its owner before reconnecting.

Precautions: Keep the existing trusted key until the intended server identity is established.

Recovery / rollback: Restore the saved host-specific configuration or DNS record if the correction targeted the wrong host.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.