# SSH Host Key Changed on Mac: Verify Before Reconnecting

An SSH host-key warning means the server identity presented now does not match the saved record. A rebuilt VPS can legitimately change its key, but a different destination can produce the same warning. Verify the endpoint and its fingerprint independently before replacing the saved entry. Changing your login key does not resolve server identity.

By the Nexus Shell team · Published September 28, 2026

This guide covers an existing server whose fingerprint changed. For a timeout, refused connection or Local Network permission issue, use the [Mac SSH connection checklist](https://nexusshell.app/en/guides/fix-mac-ssh-no-route-to-host/).

## 1. Decide whether a key change was expected

Keep an existing trusted session or provider console available. Check the server address, SSH port, VPN or jump route and the provider's rebuild or migration history.

- Expected rebuild or documented key rotation: obtain the new fingerprint through the authenticated provider console or a trusted administrator.
- No known change: stop the connection and investigate the destination. Do not repeatedly accept replacement keys.
- Different machines behind one hostname: ask the operator to verify DNS and the identities served on each route before modifying trust.
- Managed host certificates or a centrally maintained trust file: follow the administrator's rotation process. This guide's per-host replacement is for ordinary saved public keys.

A recent [openCode incident](https://discourse.opencode.de/t/gitlab-ssh-neuer-host-key-fingerprint-ed25519-seit-2026-09-20-public-key-auth-schlaegt-fehl/5816) illustrates why this matters: users reported different host keys over IPv4 and IPv6 on September 21, 2026; a platform reply said the IPv6 problem had been corrected. Later replies reported separate SSH symptoms. This is one incident, not a diagnosis of your server or a reason to disable IPv6 globally.

## 2. Compare the same key type and fingerprint

On a Linux OpenSSH server you administer, use its authenticated console to display the public host-key fingerprint. This example assumes the server actually uses the default ED25519 public-key file:

```sh
ssh-keygen -l -E sha256 -f /etc/ssh/ssh_host_ed25519_key.pub
```

Compare the complete SHA256 value and key type against the warning. An RSA fingerprint and an ED25519 fingerprint describe different keys and should not match. Custom HostKey paths, containers, appliances and host certificates need their operator's actual configuration; the default file is not universal.

The server's public host key identifies the server. Your private login key and the server's authorized_keys control who can log in. Do not send a private key, regenerate login keys or edit authorized_keys to silence a server-fingerprint warning.

[OpenSSH's server documentation](https://man.openbsd.org/sshd) describes the separate host and user authentication roles. A fingerprint obtained over the same unverified connection is not independent confirmation.

## 3. Locate the precise saved record on your Mac

For system OpenSSH, inspect the host alias's effective settings in your local Terminal. Replace example names and ports throughout; do not run a Mac-side command in the remote server's shell.

```sh
ssh -G server-alias
```

Read HostName, Port, HostKeyAlias, UserKnownHostsFile and ProxyJump. Review only your own trusted SSH configuration: Match exec rules may run local commands even while settings are being evaluated. The output can expose internal names and paths, so redact it before sharing.

Use the trust file identified by the warning and configuration. For the common ~/.ssh/known_hosts file, these commands only look up records:

```sh
ssh-keygen -F 'server.example' -f ~/.ssh/known_hosts
ssh-keygen -F '[server.example]:2222' -f ~/.ssh/known_hosts
```

The second lookup is for port 2222, not port 22. Hashed hostnames are supported. A configured HostKeyAlias, explicit IP address or different trust file may require another lookup target. Do not assume that the name you type into a client is always the stored identity. See the [OpenSSH client configuration reference](https://man.openbsd.org/ssh_config).

## 4. Replace only an independently verified stale entry

Proceed only after confirming the expected change and matching the fingerprint. Preserve a backup of the actual trust file before editing. This scoped example removes keys for server.example on port 2222 from the ordinary user trust file; it does not remove every server:

```sh
ssh-keygen -R '[server.example]:2222' -f ~/.ssh/known_hosts
ssh -p 2222 -l user server.example
```

For the default port, the lookup target is server.example without the bracket-and-port suffix. Retain any required identity or jump-host options from your working setup. Recheck the fingerprint shown at reconnect against the independently verified value before accepting it.

Do not delete the whole known_hosts file or bypass checks with StrictHostKeyChecking=no or UserKnownHostsFile=/dev/null. If a changed warning returns, investigate the route or server again. Successful identity verification can still be followed by a separate login-permission error.

[ssh-keygen's reference](https://man.openbsd.org/ssh-keygen) documents fingerprint display, hashed-host lookup and scoped removal. [ssh-keyscan's reference](https://man.openbsd.org/ssh-keyscan) warns that collecting a key without verifying it can leave users exposed to a man-in-the-middle attack: a scan is discovery, not proof of identity.

## What to do in Nexus Shell

In the website / Homebrew v1.7.7 source, a detected changed key can show a Server Fingerprint Changed dialog with the saved and current fingerprints. Choose Cancel while the change is unexplained. After checking the endpoint and independent fingerprint, Trust New Fingerprint updates that host's saved record and allows the connection to continue.

This description is a source review of the published website edition, not a GUI or customer-server test. A preflight scan may fail or take a different route from a configured jump connection; the dialog is not an independent identity authority. Do not assume that App Store builds or other SSH clients share the same trust storage or identical dialog.

Once the connection is trusted, a small task such as uptime can confirm that the session is usable. Nexus Shell keeps saved connections and terminal tabs together; SFTP, Docker and monitoring require Pro or an eligible trial. The app requires Apple Silicon and macOS 14.2+. Basic SSH is free for personal, non-commercial use.

[Download the website edition or review Pro pricing](https://nexusshell.app/en/#pricing). Website Pro remains lifetime-only. If you prefer Apple-managed purchasing, the [edition notes](https://nexusshell.app/en/#download-options) explain App Store lifetime/annual options and separate account, data and Agent Bridge boundaries. Purchasing Pro does not override server trust or login policy.

## Reproduce the lookup and replacement scope offline

Our [public Node.js rehearsal](https://github.com/viewer12/Nexus-Shell-Releases/blob/main/examples/verify-known-hosts-scope.mjs) generates disposable keys and a temporary known_hosts file, then uses the installed ssh-keygen. It never reads your SSH files or connects to a server. The [recorded result](https://github.com/viewer12/Nexus-Shell-Releases/blob/main/docs/fixtures/known-hosts-scope-result.json) passed six checks on macOS on September 28, 2026:

- Different generated host keys produce different SHA256 fingerprints.
- A hashed nondefault-port entry can be found by its exact host and port.
- Removing that entry makes its old lookup fail.
- The default-port entry and an unrelated host remain.
- The tool backup contains the removed record.
- Adding the fixture's known replacement key makes lookup return that new key.

The script cleans up its own temporary keys afterward. This demonstrates file-selection behavior only: it does not test network interception, IPv4/IPv6 routing, App Store behavior, Nexus Shell's GUI or a real VPS rebuild.