ALC-1004: SSH host key changed

The SSH server you tunnel through presented a different key from the one trusted for it. Alcuin refused to send it anything, because another machine may be posing as your server.

What you see

In the connection form, after Test connection, the heading reads Couldn't open the SSH tunnel and the message reads:

The SSH server bastion.example.com presented a different key (SHA256:…) from the one trusted for it. Someone may be posing as it. If the server's key really changed, trust the new one in the connection's settings.

Below the message, Server key shows the new fingerprint, with a red Trust the new key button.

A changed key: find out why before you choose Trust the new key.

In the launcher, after Connect, you see the same message without the button.

Why it happens

Common, harmless causes:

• The server was rebuilt or reinstalled, and its host keys were generated again.
• A cloud address or host name now belongs to a different machine.
• Several bastion hosts sit behind one name, each with its own key.

The cause this check exists for:

• Something between you and the server is intercepting the connection.

Alcuin treats the key as changed when:

• the connection’s settings hold a Trusted server key and the server’s key does not match it, or
• ~/.ssh/known_hosts lists a different key for this host and port, and the connection’s settings hold none, or
• ~/.ssh/known_hosts marks the key @revoked.

What to do

Do not click Trust the new key until you know why the key changed.

1. Ask whoever runs the SSH server whether its key changed, and for the new fingerprint, through a channel you already trust.
2. Compare it with the fingerprint Alcuin shows.
3. If they match, click Trust the new key. It replaces the Trusted server key in the connection’s settings, and Alcuin tests again.
4. Click Save to keep it.

If you saw the message in the launcher, right-click the connection and choose Edit…, then click Test connection in the form and follow the steps above. The menu’s own Test connection… reports the failure but does not offer Trust the new key.

If the fingerprints do not match, or nobody can say why the key changed, do not connect. Tell whoever runs the server.

A key marked @revoked in known_hosts is refused even after you trust it. Remove that line only if the key should be trusted again.

Your terminal’s ssh keeps its own record in ~/.ssh/known_hosts. After a real key change, ssh-keygen -R <host> removes the old entry there.

Internal name

The engine reports this as ENGINE_SSH_HOST_CHANGED. Quote either name in an issue.