An SSH key is a cryptographic credential used to prove your identity when connecting to a remote computer or service through Secure Shell (SSH). SSH keys normally come as a pair: a public key that can be placed on a server and a private key that stays on your device.
During SSH key authentication, your private key proves that you own the matching public key without the private key being sent to the server. SSH keys are widely used for Linux server administration, Git repositories, SFTP transfers, cloud servers, and automated deployments.
What Is an SSH Key?
Originally authored by Graham Morrison.
SSH stands for Secure Shell, a protocol for securely connecting to another computer over a network. Instead of authenticating with only a username and password, SSH can use public-key cryptography.
An SSH key pair contains two mathematically related keys:
- Public key: Can be copied to servers or services where you need access.
- Private key: Remains on your computer and must be kept secret.
Think of the public key as a way for a server to recognize a credential you control. The private key supplies cryptographic proof that you’re the legitimate holder of that credential.
The analogy isn’t perfect, though. Modern SSH authentication isn’t simply a server “unlocking” something with your public key. It involves digital signatures and cryptographic verification.
What Are SSH Keys Used For?
SSH keys are useful anywhere systems need secure, repeatable authentication without relying solely on passwords. Common uses include:
- Logging in to remote Linux or Unix servers
- Managing cloud servers and virtual machines
- Authenticating Git operations
- Transferring files through SFTP or SCP
- Accessing network infrastructure
- Running automated deployment or administration tasks
- Authenticating CI/CD systems where supported
For example, a developer might keep a private SSH key on a laptop and register the corresponding public key on a Git hosting service. The private key then helps authenticate Git operations without being uploaded to that service.
Public Key vs. Private Key: What’s the Difference?
The two keys work together, but they have very different security requirements.
| Feature | Public SSH Key | Private SSH Key |
| Where it typically lives | Remote server/service | Your device |
| Can it be shared? | Yes, as needed | No |
| Common filename | id_ed25519.pub | id_ed25519 |
| Main role | Verifies your authentication proof | Creates the authentication proof |
| Needs strong protection? | Not secret | Yes |
SSH Public Key
A public key is designed to be distributed to systems where you need authorization. On an OpenSSH server, a user’s authorized public keys are commonly stored in an authorized_keys file.
Someone obtaining your public key doesn’t automatically gain the ability to authenticate as you because they still lack the corresponding private key.
SSH Private Key
Your private key stays on the client device. It should never be emailed, published in a Git repository, uploaded to a website that doesn’t specifically require private-key handling for a legitimate purpose, or casually copied between systems.
Microsoft describes the private key as a credential that should remain protected and confirms that the corresponding public key can be placed on the SSH server.
How Does SSH Key Authentication Work?
The actual process is more precise than the common “digital lock and key” analogy.
A simplified SSH public-key authentication sequence works like this:
- Your SSH client connects to the server.
- The server determines whether your public key is authorized for the requested account.
- Your client uses the matching private key to create a cryptographic signature as part of the authentication exchange.
- The server verifies the signature using your public key.
- If the proof is valid and the server’s access rules allow it, authentication succeeds.
During SSH key authentication, your client uses the private key to create a cryptographic signature, while the server verifies it using the corresponding public key. The private key stays on your device throughout the process. This public key authentication process is documented in the official OpenSSH documentation.
This also explains why stealing someone’s public key isn’t equivalent to stealing their login credential. The public key can verify a valid proof, but it can’t create the private-key signature required to impersonate its owner.
Do SSH Keys Encrypt the SSH Connection?
Not directly in the way this is sometimes explained.
SSH performs several related cryptographic jobs. User authentication establishes who you are, while host authentication helps establish which server you’re connecting to. SSH also performs key exchange to establish keys used to protect the session.
So your user SSH key pair shouldn’t simply be described as “the keys that encrypt all your SSH traffic.” The protocol negotiates separate session cryptographic material for protecting the connection.
What Does an SSH Key Look Like?
An Ed25519 public key commonly looks similar to this:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI… user@example.com
It normally contains:
Key type + encoded public-key data + optional comment
The comment can help identify a key but isn’t the secret part of the credential.
A private key looks very different and may begin with a marker identifying an OpenSSH private-key block. Never publish or share the contents of your private key.
Where Are SSH Keys Stored?
On Linux and macOS, user SSH files are commonly kept in:
~/.ssh/
A typical Ed25519 pair might be:
~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub
On Windows with OpenSSH, keys are commonly stored beneath the user’s .ssh directory, such as:
C:\Users\<username>\.ssh\
Microsoft documents Windows OpenSSH key generation and deployment, including server-side authorized-key locations.
authorized_keys vs. known_hosts
These files are easy to confuse because both contain public-key-related information, but they solve different problems.
| File | Usually located on | Purpose |
| authorized_keys | Server | Controls which user public keys are allowed to authenticate |
| known_hosts | Client | Records identities of SSH servers the client has encountered/trusted |
A useful way to remember it is: authorized_keys helps the server recognize users, while known_hosts helps the client recognize servers.
How to Generate an SSH Key
OpenSSH provides the ssh-keygen utility for creating key pairs. The current OpenSSH manual supports Ed25519, RSA, ECDSA, and security-key-backed variants, among other current options.
Generate an Ed25519 SSH Key
For a typical modern setup, you can run:
ssh-keygen -t ed25519 -C “your_email@example.com”
You’ll be asked where to save the key and whether you want to protect it with a passphrase.
GitHub’s current SSH documentation also uses Ed25519 for new keys and recommends RSA for legacy systems that don’t support Ed25519.
When Would You Use RSA?
RSA remains useful when compatibility with older systems requires it. Don’t assume an older algorithm recommendation from an outdated tutorial is appropriate for a new deployment.
DSA (ssh-dss) should not be chosen for new keys; modern services such as GitHub no longer support DSA keys.
How to Add an SSH Public Key to a Server
For a typical Linux/OpenSSH server, the public key must be authorized for the account you want to access.
Where available, a convenient command is:
ssh-copy-id username@server
This copies the public key into the appropriate authorization setup on the remote system.
You can also configure the key manually by adding the public key, not the private key, to the user’s ~/.ssh/authorized_keys file.
Windows OpenSSH has some platform-specific differences. For example, Microsoft documents a separate administrators_authorized_keys location for certain administrator accounts, so don’t assume Linux paths apply universally.
How to Connect Using an SSH Key
Once the public key is authorized on the server, a normal connection may be as simple as:
ssh username@server
OpenSSH can automatically use an appropriate identity from its configured/default locations.
To explicitly choose a private key:
ssh -i ~/.ssh/id_ed25519 username@server
The server checks whether the corresponding public key is authorized and verifies your authentication proof.
SSH Keys vs. Passwords
SSH keys and passwords can both authenticate users, but their security characteristics differ.
| Feature | SSH Key | Password |
| Resistant to password guessing | Yes | Depends on password strength and controls |
| Useful for automation | Yes | Usually less suitable |
| Main secret | Private key | Password |
| Local protection | Passphrase, agent, hardware-backed options | Password manager, device/account protections |
| Revoking access | Remove public-key authorization | Change/disable password/account |
SSH keys aren’t automatically safe just because they use cryptography. An exposed private key can become a serious credential compromise, especially if it has broad access and no additional protection.
SSH Key Types: Ed25519, RSA, ECDSA and DSA
Ed25519 is a strong modern choice for new SSH keys where supported and is the default key type in the current OpenSSH ssh-keygen manual.
RSA remains widely supported and can be appropriate when compatibility is important.
ECDSA is another supported public-key algorithm, although beginners generally don’t need to choose it over Ed25519 without a specific requirement.
DSA is obsolete for modern SSH deployments and shouldn’t be selected for a new key.
What Is an SSH Key Passphrase?
A private-key passphrase and your server password are not the same thing.
A server password is an account credential used by the remote system. An SSH key passphrase protects the private-key file stored on your device.
If someone obtains a passphrase-protected private-key file, the passphrase adds another barrier to using it.
You can also use ssh-agent to manage loaded private keys so you don’t have to repeatedly enter the passphrase. GitHub’s documentation describes this workflow and recommends passphrases as an additional layer of protection.
What Happens If an SSH Key Is Stolen?
The answer depends on which key is exposed.
If your public key becomes visible, that’s generally not a credential emergency. Public keys are intended to be distributed where necessary.
If your private key is exposed, treat it as compromised. Remove the corresponding public key from servers and services where it grants access, generate a replacement pair, and review relevant access logs or account activity.
Don’t simply change the key’s comment or filename. That doesn’t invalidate the compromised private key.
Common SSH Key Problems
Permission denied (publickey)
This error means the server didn’t accept the public-key authentication attempt. Common causes include:
- connecting with the wrong username
- using the wrong private key
- public key missing from authorized_keys
- incorrect SSH file permissions on systems that enforce them
- SSH client not selecting the intended identity
- server configuration not permitting that key or authentication method
If you have multiple identities, specifying one explicitly with ssh -i can help determine whether the wrong key is being selected.
Host Key Has Changed
A host-key warning is different from your user SSH key failing.
The host key identifies the server. An unexpected change can happen after a legitimate server rebuild or host-key replacement, but it can also indicate that you’re connecting to a different system than expected. Verify the new fingerprint through a trusted source before accepting an unexplained change.
SSH Key Security Best Practices
Keep the private key private and limit where copies exist. Use a passphrase when appropriate, particularly on portable or user-operated devices.
Also:
- Prefer current algorithms such as Ed25519 when compatible.
- Remove public keys that no longer require access.
- Don’t commit private keys to source-code repositories.
- Give keys only the access their owner or automation actually needs.
- Replace credentials promptly after suspected private-key exposure.
- Use ssh-agent or suitable secure key storage rather than scattering unprotected copies.
- Consider hardware-backed SSH credentials for higher-risk environments.
Large organizations should also know which keys exist, who owns them, and which systems authorize them. Forgotten keys can become long-lived access paths.
Frequently Asked Questions
Is an SSH key a password?
No. An SSH key is a cryptographic credential. A private key proves possession of the credential, while a password is a secret string submitted through the protected connection for password authentication.
Is it safe to share my SSH public key?
Yes, public keys are designed to be distributed to systems where you need access. Your private key is the part that must remain secret.
Should I use RSA or Ed25519?
Ed25519 is a good modern choice where it’s supported. RSA can still be appropriate when compatibility requirements call for it.
Where can I find my SSH key?
On Linux and macOS, check ~/.ssh/. With Windows OpenSSH, check the .ssh directory under your user profile.
Can I use the same SSH key on multiple servers?
Technically, the same public key can be authorized on multiple servers. Separate keys can make access isolation and revocation easier when systems have different security roles or owners.
What does Permission denied (publickey) mean?
It means the server didn’t accept your public-key authentication attempt. Check the username, selected private key, server-side authorized key, permissions, and SSH configuration.
Can an SSH key expire?
A basic OpenSSH public key doesn’t inherently have to expire as a password policy might require. Organizations can impose lifecycle controls, and SSH certificates can have defined validity periods.
What’s the difference between an SSH key and a host key?
A user SSH key normally authenticates you to the server. A host key helps authenticate the server to you, reducing the risk of silently connecting to an unexpected machine.
