Creating and using SSH keys

In this step-by-step article, you'll learn how to create an SSH key, transfer it to your server, and disable password authentication to multiply your server's security.

8 min Updated 16 Aug 2026

If you've ever used a password to connect to a Linux server, you probably know that this method is not only slow and tedious, but it's also one of the biggest security weaknesses of your server. Brute-force attacks against the SSH service are among the most common threats that any internet-connected server faces daily. The standard and almost mandatory solution to this problem is using an SSH key. In this article, in simple language and with practical examples, you'll learn how to create a key pair, place the public key on the server, and finally disable password authentication entirely.

What is an SSH key and why should you use it?

An SSH key is an authentication method based on asymmetric cryptography. Instead of sending a password over the network (which is always susceptible to eavesdropping or guessing), you use a mathematical key pair: a private key that is stored only on your system (the client) and a public key that is placed on the server. When you want to log into the server, the server sends an encrypted challenge that can only be solved with your private key. This process is not only more secure but also enables passwordless login.

The main advantage of this method is that the private key never leaves your device, and no password travels across the network. Even if someone intercepts network traffic, they won't gain any useful information. Additionally, you can set a passphrase for your private key so that even if someone gains access to your key file, they cannot use it.

Prerequisites and Preparation

To follow this tutorial, you'll need the following:

  • A Linux server (Ubuntu, Debian, CentOS, or any other distribution) with SSH access
  • A client system (laptop or personal computer) from which you want to connect to the server
  • Terminal access on both systems

On Linux and macOS systems, the ssh-keygen tool is installed by default. If you're using Windows, newer versions of Windows 10 and 11 include OpenSSH, and you can use PowerShell or CMD. To make sure it's installed, run the following command:

ssh -V

If the output includes the OpenSSH version, everything is ready.

Creating an SSH Key Pair

The first step is to generate a key pair on your client system. Run the following command in your terminal:

ssh-keygen -t ed25519 -C "your_email@example.com"

In this command:

  • -t ed25519 specifies the encryption algorithm. ed25519 is faster and more secure than RSA and produces shorter keys. If your server doesn't support this algorithm (very old servers), you can use rsa with a length of 4096 bits: ssh-keygen -t rsa -b 4096
  • -C adds a comment (usually your email) to the key so you can later identify which key belongs to which system.

After running the command, you'll be asked where to save the key file. The default path is ~/.ssh/id_ed25519, which is usually the best option. Just press Enter. Then you'll be prompted to set a passphrase. This is an additional password for the private key itself. If you want extra security, enter a long phrase. If you prefer passwordless login, you can leave it empty, but this reduces security.

After this step, two files will be created in the ~/.ssh/ directory:

  • id_ed25519 — the private key (never share this file with anyone)
  • id_ed25519.pub — the public key (this is the file we'll place on the server)

To view the contents of the public key, use the following command:

cat ~/.ssh/id_ed25519.pub

The output will look something like this:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIK8J3hY8xQy7vZ2mX9sLpQnR4vKcWxTz6HjYbGfQ your_email@example.com

Copy this string; you'll need it in the next step.

Common Mistake: Using the Private Key Instead of the Public Key

One of the most common mistakes is copying the contents of the id_ed25519 file (the private key) instead of id_ed25519.pub (the public key). Never do this. The private key must always remain on your system, and if it falls into someone else's hands, they can log into your server without a password.

Transferring the Public Key to the Server

Now that you have the public key, you need to add it to the ~/.ssh/authorized_keys file on the server. The simplest and most reliable method is using the ssh-copy-id command. This command automatically transfers the public key to the server and places it in the correct location:

ssh-copy-id username@server_ip

Replace username with your username on the server and server_ip with the server's IP address or domain. The first time, you'll be prompted for the user's password. After entering the password, the public key will be added to the authorized_keys file.

If for any reason ssh-copy-id isn't available (for example, on Windows), you can do this manually. First, log into the server with your password:

ssh username@server_ip

Then, on the server, create the .ssh directory and the authorized_keys file:

mkdir -p ~/.ssh
touch ~/.ssh/authorized_keys

Now append the contents of the public key (which you copied earlier) to the end of the file. You can use the nano editor:

nano ~/.ssh/authorized_keys

Paste the content, then save and exit with Ctrl+X, Y, and Enter. Finally, set the correct permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

These permissions are very important. If the files are too permissive, the server may refuse to accept the key.

Testing the Connection with the SSH Key

Before disabling password authentication, make sure to test the key-based connection. From your client system, run the following command:

ssh username@server_ip

If everything is set up correctly, you'll log into the server without being prompted for a password (though if you set a passphrase for your private key, you'll be asked to enter it). If you receive an error like Permission denied (publickey), the public key was probably not added correctly, or the permissions are wrong. Double-check the permissions and make sure the public key content was copied exactly on one line without extra spaces.

Disabling Password Authentication

After confirming that SSH key authentication works correctly, it's time to disable password authentication. This prevents brute-force attacks and elevates your server's security to a higher level.

First, edit the SSH configuration file:

sudo nano /etc/ssh/sshd_config

In this file, look for the following lines and change their values:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

If these lines don't exist, add them at the end of the file. Note that PasswordAuthentication no is the most important line. After applying the changes, save the file and restart the SSH service:

sudo systemctl restart sshd

On Debian-based distributions (such as Ubuntu), the service name might be ssh instead of sshd. In that case, use the command sudo systemctl restart ssh.

Common Mistake: Locking Yourself Out of the Server

The biggest risk at this stage is that if your key doesn't work correctly, after disabling password authentication, you'll have no way to log into the server. To prevent this disaster, do two things:

  1. Before disabling password authentication, open a second SSH session to the server and keep it open. If something goes wrong, use that session to fix the configuration.
  2. After changing the configuration and before closing the current session, test the key-based connection in a new terminal. If it succeeds, you can close the old session.

It's also recommended to back up the configuration file before making changes:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

If a problem arises later, you can restore the configuration with the following command:

sudo cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config

Managing Multiple Keys and Using ssh-agent

If you use multiple servers, you might create a separate key for each one. For better management, you can create the ~/.ssh/config file on your client system. This file allows you to define an alias for each server and apply specific settings. Example:

Host myserver
    HostName 192.168.1.100
    User root
    IdentityFile ~/.ssh/id_ed25519_server1
    Port 22

Now, instead of typing a long command, you can simply write:

ssh myserver

If you've set passphrases for your keys, entering them on every connection can be annoying. In that case, you can use ssh-agent, which keeps keys in memory and, after entering the passphrase once, won't ask again as long as the system is running:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

After this, within the same terminal session, connections to the server will be made without prompting for the passphrase.

Additional Tips for Enhanced Security

Disabling password authentication is just one step in securing SSH. To further protect your server, consider the following:

  • Changing the SSH port: Changing the default port 22 to an uncommon port drastically reduces automated attacks. Do this in sshd_config with the line Port 2222.
  • Restricting allowed users: Use the line AllowUsers username to permit only specific users to log in.
  • Using fail2ban: This tool automatically blocks IPs that have multiple failed attempts.
  • Disabling root login: Use the line PermitRootLogin no to disable direct root login, and always log in with a regular user and then use sudo to run commands.

If you're looking for a secure and scalable infrastructure for your projects, ServerNet cloud servers with full SSH support and advanced management features can be a great choice.

Conclusion

Using SSH keys is an essential skill for every server administrator. By following the steps in this article, you learned how to create a key pair, place the public key on the server, and finally disable password authentication. This not only significantly increases your server's security but also makes your daily workflow with the server much smoother. Always remember to back up your configuration before applying security changes and to test the new connection before closing the current session. By following these tips, you can confidently enjoy the benefits of key-based authentication.

Was this page helpful?