SSH keys can be confusing because “my SSH key” might mean a credential you use to log in—or a key the server uses to prove its identity. Those keys have different owners and jobs. Mixing them up can lead to authentication failures or, worse, trusting the wrong server.
The two halves of a login key
For user authentication, an SSH key is a public/private pair:
- The private key stays under your control. Your SSH client uses it to prove that you possess the credential.
- The public key is shared with a server or service that should allow your access.
On a typical OpenSSH setup, a private key might be named ~/.ssh/id_ed25519, with its matching public key at ~/.ssh/id_ed25519.pub. These names and locations are common defaults, not requirements; keys can use other filenames or credential stores.
The .pub suffix is a useful clue, but check the file’s contents and context rather than relying on a name alone. Public keys are intended to be distributed. Private keys are secrets: don’t paste them into websites, send them to a server, or commit them to a repository.
If you need to create a pair, follow a practical SSH key generation guide and keep the private and public files straight.
What happens during key authentication?
The server has to authorize your public key for the account you’re trying to access. In a common OpenSSH setup, that public key is listed in the account’s ~/.ssh/authorized_keys file on the server.
When you connect, your client offers a public key. If the server recognizes it as authorized, the client proves possession of the matching private key by creating a cryptographic signature. The server checks that proof with the public key. The private key itself is not sent over the network.
A successful key match is only one part of login. The username must be right, the key must be authorized for that account, and server policy must allow the authentication method. That’s why having a key on your laptop does not automatically grant access to every server.
Host keys answer a different question
A user key answers: “Is this client authorized to log in?” A host key answers: “Is this the server I meant to reach?”
The SSH server keeps its host private key. Your client checks the corresponding public host key and commonly remembers it in known_hosts. This verification helps detect when a server’s identity differs from what your client previously trusted.
A host-key warning is not the same as a rejected user key. A server rebuild or other legitimate change can produce a new host key, but an unexpected change can also mean you are connecting to a different machine. Verify the new fingerprint through a trusted channel before accepting it. Don’t disable host-key checking just to make the warning go away. If you encounter the specific “REMOTE HOST IDENTIFICATION HAS CHANGED” message, use this safe host-key warning workflow.
A passphrase protects the local key file
A passphrase can encrypt a private-key file at rest. When you use that key, you may need to unlock it directly or through an SSH agent or another credential tool.
It is not your remote account password, and public-key authentication does not send it to the server. The passphrase protects the local key file; it doesn’t change which keys the server authorizes. Protect the device and private-key file too. If someone can use an already-unlocked key, the passphrase may not stop them.
Key-based login also doesn’t necessarily mean there are no passwords involved: the server might still allow account-password authentication, and the private key may require a passphrase.
Quick checks when login fails
Start by identifying which part of the exchange is failing:
- Check the account and destination. A valid key won’t help if you’re connecting as the wrong user or to the wrong host.
- Check which key your client is using. You might have more than one key, or a key stored under a non-default filename.
- Check server authorization. The public key must be authorized for the account you’re logging into; having it on a different account is not enough.
- Keep warning types separate. A rejected user key concerns login authorization. A changed host key concerns the identity of the server.
The core distinction is simple: keep the user’s private key private, install or register its public counterpart where access is needed, and treat the server’s host key as a separate identity check. Knowing which key is involved makes SSH errors much easier to reason about.
If a private key is exposed, assume it may be compromised. Remove or revoke its public key wherever it is authorized, then create a replacement pair and grant access only where needed. Adding a passphrase after exposure does not undo the exposure.
I originally published a more detailed version of this guide on the SSHFlow blog.
I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.
Top comments (0)