Skip to content

10AM–5PM by appt.
24h urgent appts

📞 0279-088880

All prices include GST

Cart
0 items

Computer Repair Guides

Verify a Changed SSH Host Key Before Replacing Its Saved Identity

by AEPC / AKL East PC 28 Sep 2026

A changed SSH host-key warning can follow a legitimate server rebuild, but it can also mean you reached a different machine. Treat it as an identity question before treating it as an inconvenient login failure. Keep the exact hostname, port, key type and displayed fingerprint.

Verify through an established route

Ask the responsible administrator whether the server was rebuilt or its host keys deliberately rotated. Obtain the current fingerprint through a previously trusted management console or established contact channel. A fingerprint copied from the same unverified connection is not an independent comparison.

Compare the complete fingerprint for the same key type and destination. Check whether an address was reassigned or the saved connection points at an old host. Do not substitute a similar hostname because its login screen looks familiar.

OpenSSH stores known host identities and warns when they change. The administrator can inspect a server public-key fingerprint with ssh-keygen -l -f followed by that public-key file's path. No private server key needs to be sent to the client.

Correct only the verified entry

On the client, ssh-keygen -F can find the saved hostname, including hashed entries; a nonstandard port uses the documented [hostname]:port form. Preserve a copy of the existing known_hosts file before changing it.

Only after the replacement identity is independently confirmed should you remove that destination's old entries with ssh-keygen -R using the same host-and-port scope. Do not delete the whole file or disable host-key checking to clear a single warning.

Reconnect to the intended destination and compare the presented fingerprint again before accepting it. Record who confirmed the change and which server maintenance explained it. If the fingerprint still differs, stop the connection and return that discrepancy to the administrator.

After authentication, confirm the expected account and server context before performing work. A repaired trust record is not evidence that a previous transfer or remote command completed; inspect those outcomes separately before repeating them.

Sources: Ubuntu documentation, Ubuntu documentation.

Prev Post
Next Post

Thanks for subscribing!

This email has been registered!

Shop the look

Choose Options

Edit Option
Terms & Conditions
Unless otherwise stated, brand new accessories are guaranteed for one year. Second-hand parts are guaranteed for three months. Repair (hardware) is guaranteed for one month. The software is not covered by the warranty, you should contact the software development organization for technical support and after-sales service. The warranty is limited to the same position fault; the customer should provide the warranty with the complete Warranty sticker and the receipt of payment. Otherwise, it will not be guaranteed. (If the warranty label is damaged for any reason, is not covered by warranty.) Returns and refunds Please read our Return & Refund Policy for the current return timeframe, conditions, fees, return methods and refund processing time.
this is just a warning
Login
Shopping Cart
0 items