Why the fingerprint matters
A hostname tells LeapTerm 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 first connection needs an independent identity check. 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 observed fingerprint in Connection Details.
- 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.
A successful connection or a verification badge does not replace your independent comparison, especially when no host pin was previously saved.
Review imported host keys
Import hosts can retain actual public keys from an OpenSSH known_hosts file and use their fingerprints as connection pins. Confirm the source and destination before accepting the import. Importing only an address does not establish its identity.
If several keys are imported for one host, review the warning: the first imported key is the connection pin. Certificate-authority and revoked-key entries cannot be converted into ordinary host pins by this importer.
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.
In a supported installed Protected workspace, independently verify the customer agent's public key before checking the confirmation under Device enrollment. Approve the exact public device key produced locally through the customer's trusted signing process. Account login and a relay admission token do not perform those checks.
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.