Managing a remote server often requires a secure way to connect without physically accessing the machine. For Linux and other Unix-like systems, SSH, or Secure Shell, is one of the most common technologies used for remote administration.
Many servers can accept password-based SSH logins, but passwords can be vulnerable to guessing, reuse, phishing, and other security problems. SSH keys provide an alternative authentication method that uses cryptographic credentials instead of relying solely on a password.
An SSH key pair contains two related keys: a private key and a public key. The public key can be placed on a server, while the private key remains securely with the person or system connecting to it.
This guide explains what SSH keys are, how they work, how to create and install them, and what users should do to protect their private keys.
What Are SSH Keys?
SSH keys are cryptographic credentials used to authenticate a user or device when connecting to an SSH server.
Unlike a traditional password, an SSH key pair consists of two separate components:
- Public key: Stored on the server and designed to be shared.
- Private key: Kept secret on the user’s computer and should never be shared.
The two keys are mathematically related. During authentication, the SSH client can prove that it possesses the private key corresponding to the public key stored on the server.
The private key itself does not need to be sent to the server during normal authentication.
This design makes SSH keys particularly useful for administrators, developers, cloud environments, and automated systems that need reliable server authentication.
How SSH Key Authentication Works
The basic process is straightforward.
First, a user creates an SSH key pair on their local computer. The resulting public key and private key are saved separately.
The public key is then added to the appropriate account on the remote server. When the user later attempts to connect, the SSH server checks whether the client can authenticate using the corresponding private key.
A simplified process looks like this:
Local computer -> SSH connection -> Remote server -> Public-key authentication -> Access granted
The private key stays on the local device. The server only needs the corresponding public key.
For additional protection, a private key can also be protected with a passphrase. This means that someone who obtains the private-key file may still need the passphrase to use it.
Why SSH Keys Are More Secure Than Passwords
SSH keys can provide several security advantages over passwords.
Passwords are often short enough to be guessed or reused across multiple services. Users may also accidentally expose passwords through phishing attacks or insecure storage.
A properly generated SSH key can be much harder to guess because it is based on cryptographic algorithms rather than a human-created phrase.
SSH keys can also support automated systems. For example, a deployment service may need to authenticate to a server without a person manually entering a password every time.
However, SSH keys are not automatically secure simply because they are keys. The private key must be protected carefully. If an unauthorized person obtains a usable private key, they may be able to authenticate as its owner.
Choosing an SSH Key Algorithm
Modern SSH implementations support several key types.
Ed25519 is a popular choice for new SSH keys because it provides strong security while using relatively small keys and efficient cryptographic operations.
RSA keys are also widely supported, especially on older systems. When RSA is used, a sufficiently large key size should be selected.
For most modern systems, Ed25519 is a convenient default when compatibility is not a concern.
Before creating a key, users should also check the SSH version and operating system documentation if they are working with an older server.
How to Generate an SSH Key Pair
On Linux, macOS, and many other Unix-like systems, the ssh-keygen command can create an SSH key pair.
A typical command is:
ssh-keygen -t ed25519The command asks where the key should be saved and whether the private key should have a passphrase.
For example, the default location is commonly:
~/.ssh/id_ed25519The corresponding public key normally ends with .pub:
~/.ssh/id_ed25519.pubThe important distinction is simple:
Never share id_ed25519 as the private key.
The .pub file is the public key and can be added to the server.
A passphrase is strongly recommended for protecting the private key, particularly on computers that could be lost, shared, or accessed by other people.
Adding the Public Key to a Server
After generating the key pair, the public key needs to be added to the account that will be used for SSH access.
On systems that provide ssh-copy-id, a user can copy the public key to an authorized account with:
ssh-copy-id username@server-addressThe command typically asks for the account’s current authentication method so that the public key can be installed.
After the key has been added, the user can test authentication with:
ssh username@server-addressIf everything is configured correctly, the SSH client should use the private key to authenticate against the public key stored on the server.
Some environments do not provide ssh-copy-id. In that case, the public key can be added to the user’s SSH authorization file on the server.
The relevant file is usually:
~/.ssh/authorized_keysEach authorized public key is normally stored on its own line.
Protecting the SSH Private Key
The private key is the most important part of an SSH key pair from a security perspective.
It should never be posted online, sent through chat, uploaded to public repositories, or copied into documents that other people can access.
On Linux and macOS, users should also make sure the private key has appropriate file permissions. A commonly used permission setting is:
chmod 600 ~/.ssh/id_ed25519This restricts access to the file for the owner.
A strong passphrase provides another layer of protection. SSH agents can also help users avoid repeatedly entering the passphrase during a working session.
Users should treat private SSH keys similarly to other sensitive authentication credentials.
Testing SSH Access Safely
After installing a public key, it is important to test the connection before making additional authentication changes.
A user can connect with:
ssh username@server-addressIf the connection succeeds using the intended key, the setup is working.
For troubleshooting, SSH provides verbose output through the -v option:
ssh -v username@server-addressMore detailed levels such as -vv and -vvv are also available.
Verbose output can help identify issues involving key locations, authentication methods, permissions, or SSH configuration.
Users should avoid changing multiple security settings at the same time. Making one controlled change and testing it first makes troubleshooting much easier.
Disabling Password Authentication
Once key-based authentication has been tested successfully, server administrators may choose to disable password-based SSH authentication.
This can reduce exposure to password-guessing attempts, but it should be done carefully.
The SSH server configuration is commonly stored in:
/etc/ssh/sshd_configDepending on the operating system and SSH version, the exact configuration can vary.
Before disabling passwords, administrators should confirm that:
- The SSH key works correctly.
- A backup access method is available.
- Another administrative session remains open during testing.
- The configuration syntax is valid.
- The SSH service can be safely reloaded or restarted.
A configuration mistake can prevent legitimate users from connecting. Therefore, server administrators should understand their hosting environment and recovery options before changing authentication settings.
Common SSH Key Problems
SSH key authentication can fail for several reasons.
Incorrect File Permissions
If the private key or server authorization files have overly permissive permissions, SSH may reject them.
Wrong Username
The public key must be installed for the correct server account. A key placed under one account does not automatically authenticate another account.
Wrong Key
A computer can contain several SSH keys. The client may attempt to use a different key than the one installed on the server.
Incorrect Server Configuration
The SSH server may be configured to restrict public-key authentication or accept keys only under specific conditions.
Public Key Formatting Problems
The public key normally needs to remain on a single line in the authorization file. Accidental line breaks or modifications can make the key unusable.
Lost Private Key
If the private key is deleted and there is no backup or alternative authentication method, access may need to be restored through another administrative route.
SSH Keys for Multiple Servers
SSH keys become particularly useful when a person manages several servers.
A single public key can potentially be authorized on multiple systems, although security teams may prefer separate keys for different environments.
For example, separate keys could be used for:
- Development servers
- Testing environments
- Production systems
- Personal projects
- Automated deployment systems
Separating credentials can make access management easier. If one key needs to be revoked, other environments do not necessarily have to be affected.
The SSH configuration file can also help organize connections. A user may create entries in:
~/.ssh/configThis allows convenient aliases and per-server settings without repeatedly entering long connection details.
SSH Key Management Best Practices
Creating SSH keys is only the beginning. Good key management is equally important.
A few practical principles include:
- Protect private keys with strong passphrases.
- Never share private keys.
- Keep private keys out of public repositories.
- Use modern key types where compatible.
- Remove old or unnecessary public keys from servers.
- Use separate keys when appropriate.
- Keep operating systems and SSH software updated.
- Review who has administrative access.
- Maintain a secure recovery method.
- Monitor important servers for unusual authentication activity.
Organizations should also maintain an inventory of authorized keys. Over time, unused keys can accumulate, making access management harder.
Conclusion
SSH keys provide a practical and secure way to authenticate with remote servers. Instead of relying entirely on passwords, SSH key authentication uses a cryptographic pair consisting of a public key and a private key.
The setup process involves generating a key pair, placing the public key on the server, testing the connection, and protecting the private key. Administrators can also consider disabling password-based SSH authentication after confirming that key-based access works correctly.
For anyone managing Linux servers, cloud infrastructure, development environments, or remote systems, learning proper SSH key management is an important part of maintaining secure server access.
Frequently Asked Questions
1. What is an SSH key used for?
An SSH key is used to authenticate a user or system when connecting to an SSH server. It can provide an alternative to password-based authentication.
2. Is an SSH private key safe to share?
No. A private SSH key should remain secret. Only the corresponding public key should normally be placed on a server or shared for authentication purposes.
3. Should an SSH private key have a passphrase?
Yes, using a passphrase is generally recommended. It provides an additional layer of protection if someone gains access to the private-key file.
4. Where are SSH keys stored?
On Linux and macOS, SSH keys are commonly stored inside the user’s ~/.ssh/ directory. Windows systems can also use an .ssh directory, depending on the SSH client and configuration.
5. What happens if an SSH key is lost?
If the private key is lost, it generally cannot be reconstructed from the public key. Access may need to be restored using another authorized key, account, console, or recovery method.
6. Are SSH keys better than passwords?
SSH keys can provide stronger authentication than passwords when they are generated, stored, and managed properly. However, protecting the private key remains essential.