Why the fingerprint matters
A hostname tells OmniTerm where to connect. A host key identifies the SSH server that answers. Checking its fingerprint helps prevent a different machine from impersonating your server, even when the address looks familiar.
A new-server prompt means the identity has not yet been trusted in that context. A changed fingerprint needs attention: it can follow a legitimate rebuild or key rotation, but it can also mean a wrong destination or an attack.
Verify the identity
- Read the hostname, port and fingerprint shown by OmniTerm.
- Obtain the expected fingerprint independently from the administrator or a trusted management console.
- Compare the complete fingerprint, not just its first or last characters.
- Trust the identity only after it matches and you understand any change.
- Stop when the identity cannot be verified.
Do not use the same unverified connection to ask the unknown machine whether it is trustworthy. That only asks the unknown party to vouch for itself.
Relay connections still need verification
An enrolled agent and the destination SSH server can have separate identities. Verifying the relay's HTTPS certificate, the agent identity and the target host solves different problems. A familiar relay address does not prove the destination is correct.
Do not disable certificate verification to suppress an error. For a private deployment using its own certificate authority, have the administrator distribute the appropriate trust configuration through an authenticated channel.
Read how relay works for the connection sequence, or troubleshooting for reachability errors unrelated to identity.