Two identities are involved
SSH verifies the server's identity and authenticates your user account. Your private key proves who you are; the server's fingerprint helps prove which machine you reached. Neither check replaces the other.
A key passphrase protects a private key. It is separate from your server password, OmniTerm sign-in and vault password. Check which credential a prompt is requesting before entering it.
Use an SSH identity
- Open the supported identity-management options under Keys & Security. Import private material only from a source you trust.
- Have the corresponding public key authorized for your username on the server.
- Edit the server profile and select that identity under Authentication & Security.
- Unlock the vault or private key when requested, then connect.
- Verify the server fingerprint independently before trusting a new host.
The server must permit your chosen method. A key-only server does not additionally require a password; a password or interactive login can have a different prompt sequence.
Handle keys carefully
Private keys must not appear in tags, snippets, support messages or screenshots. An unavailable native keyring is not an instruction to save them unprotected elsewhere.
With an enrolled relay route, your client can also prove permission to reach the agent. That check is separate from logging in to the destination server. A relay token does not replace the destination's authentication requirements.
For a failed login, check username, selected identity, passphrase and server-side authorization. For an identity warning, follow host verification, not a password-reset workflow.