A BIND SSH host-key mismatch means Domain Nexus cannot verify that it is talking to the server previously trusted for this connection. The adapter checks that identity before sending login credentials. After a legitimate server rebuild, replace the saved fingerprint only after verifying the new host through a trusted channel.
IN THIS ARTICLE
01 Confirm the reason for the change
- Check the server-rebuild or SSH-key-rotation record. Confirm the hostname, IP address and infrastructure instance are the intended replacement.
- Open the server through the provider's trusted console or another independently authenticated administrative channel.
- Identify the SSH host public key actually offered by that server and obtain its SHA256 fingerprint. For an Ed25519 host public key on a typical OpenSSH installation, an administrator can read it with the command below.
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256This reads a public host key. It does not generate a new key or reveal a private login key. Use the actual host-key file and algorithm for your server rather than assuming every installation offers the same key.
02 Update and validate
- Compare the independently verified value with the server identity expected for the Domain Nexus connection.
- Edit the BIND connection's Trusted SSH host-key fingerprint and save the complete
SHA256:value. - Run the connection check. If the identity check now passes but login fails, diagnose the SSH username, authorised key and permissions separately.
- Read an existing managed zone and confirm its include file and
rndcaccess before resuming pending writes.
Can I use an unauthenticated scan as proof?
No. A network scan can show the key currently presented on that path, but it does not independently establish who controls the endpoint. Compare against trusted console evidence before accepting a replacement.
Should I rotate the SSH login key too?
A host key identifies the server; a login key authenticates the account. A planned rebuild may require either or both changes, but they are separate decisions. Do not paste the login key's fingerprint into the host-key field. Preserve the mismatch evidence if the change was unexpected and investigate before reopening DNS writes.