Secure SSH Authentication with a Key Pair
Introduction
SSH stands for “Secure Shell” and is a network protocol that allows establishing a secure, authenticated, and encrypted connection over a network to a server. Originally, it was developed for secure access to remote command lines. There are also extensions, like “SFTP”, for secure file and directory transfer. In this article, we will show how, instead of a password, a pair of cryptographic keys can be used for authentication. A key pair is generated, with the key length being significantly longer than that of a password. Thanks to SSH public key authentication, a single connection can also be easily achieved by storing the public key on multiple servers.
SSH is also often used as a transfer medium for distributed source code version management git.
How does authentication with a key pair work?
For authentication, both the server and the client each generate two keys: a public key and a private key. The private key must always remain secret, while the public key can be made public. It is impossible to deduce the private key from the public key. However, without knowing the private key, it is possible, using a person’s public key, to verify if data has been signed with that person’s private key. This mechanism forms the basis of authentication when establishing an SSH connection.
The process of establishing the connection from the client to the server using public key authentication proceeds in a simplified manner as follows:
- The client establishes a connection with the server.
- The server sends its public key to the client.
- The client compares the public key sent by the server with the one it knows for that server. If the public key differs from the one known to the client, the connection is terminated. If the client does not know the server’s public key, it asks the user if it should save the server’s fingerprint during the first connection.
- The server verifies if the client possesses the private key using the key registered on it.
The private key is generally encrypted with a passphrase on the personal computer. Before use, the private key must therefore first be decrypted. To avoid this at each connection to a server, the decrypted private key can be stored in an “SSH-Agent”, thus allowing local SSH clients to access it as needed. Entering a password at each connection to a server is therefore avoided.
Storing the public key on the target system
The commonly used OpenSSH server on Linux generally looks for the public key in the ~/.ssh/authorized_keys file when the client connects. The abbreviation ~ represents your home directory on the server, for example /home/bob/. If the corresponding key is found there, the user’s connection is authorized.
You must therefore copy your public key into the ~/.ssh/authorized_keys file on the server. Your public key is generally found in the ~/.ssh/id_rsa.pub file on the computer where you generated your key pair.
Linux Clients
Generating a Key Pair
A key pair can be generated on Linux with the command
ssh-keygen -t rsa
Here, you will be prompted to choose a passphrase. This is a password that encrypts the private key stored in a file on your computer to protect it against unauthorized access.
To avoid having to manually copy the public key, there is the ssh-copy-id tool on Linux. This tool can be used as follows, for example for the user “bob”:
ssh-copy-id bob@server.example.com
You will be prompted to enter the password for the SSH connection, and the tool will save the public key on the server. Then, you can test the connection on the target system:
ssh bob@server.example.com
Using the SSH Agent
Since you have generally protected your private key with a passphrase, you will need to enter it at each connection to the SSH server. To avoid this, a daemon has been created that runs in the background on your computer and temporarily stores the passphrase in memory. On most Linux desktop computers, this daemon is started automatically, so by running the command
ssh-add
the existing unlocked private key can be added to the agent.
In case of an error because the daemon is not running, it can be started with the command
eval `ssh-agent`
by automatically setting the appropriate environment variables in the current shell.
Windows Clients
Since version 1709, Windows 10 also includes an SSH client by default. Therefore, it is not necessary to install additional software, as on most Linux systems. On older versions of Windows, you can use, for example, the Putty tool.
To use the client, please start Microsoft PowerShell.
Here, you can generate a new key pair with the command ssh-keygen -t rsa, where you will also be prompted to enter a passphrase:
You can then display your public key with cat ~/.ssh/id_rsa.pub:
Your public key must now also be stored on the server. To do this, connect to the server with the command ssh bob@example.com and edit the ~/.ssh/authorized_keys file with a text editor like “nano”:
nano ~/.ssh/authorized_keys
After entering your public key on the server, you should no longer be prompted to enter a password when connecting to the server.
Securing the target system
Once the public keys are stored on the Linux server, it is advisable to increase security by disabling password authentication on the server. Before disabling password authentication, please check if the connection via SSH public key authentication works without having to enter a password for the server.
This can be configured in the /etc/ssh/sshd_config file on the server with the following line:
PasswordAuthentication no
After making changes to this file, the SSH server must be restarted. This can be done on Linux systems using “systemd” by entering the following command:
systemctl restart ssh.service
The current SSH connection is generally maintained.
File Transfer with SCP
The “Secure Copy” (SCP) protocol, based on SSH, allows transferring files and directories, which can be done, for example, for a directory using the following command:
scp -r /home/bob/Documents/ bob@server.example.com:/home/bob/Backup/
Additionally, there is the SFTP protocol, which, unlike SCP, also allows the transfer of directory rights. However, it operates interactively, making file transfer a bit slower. For SFTP, you can use, for example, the FileZilla client.
Clients of both protocols can generally access an SSH agent.
Managing Users and Permissions
OpenSSH lets you control who can access your server and what they can do. You can enable or restrict login for specific users, limit which commands they can run, or block password-based login entirely. Fine-tuning these settings helps keep your system safe by ensuring only authorized people can connect. If you manage multiple users, adjusting permissions also helps keep everything organized. For example, admins can have full access while developers may only access certain directories. Clear access rules keep your server secure and easier to maintain.
Hardening Your SSH Configuration
Improving your SSH configuration reduces vulnerabilities and lowers the chance of unauthorized access. Small adjustments can make a meaningful difference. For example, changing the default port, disabling root login, or limiting authentication methods can help keep attackers out without affecting how you work. You can also specify which IP addresses are allowed to connect or enforce key-based authentication only. Each improvement adds a layer of safety with minimal complexity.
Security tips you can apply:
- Disable password authentication once SSH keys are in place
- Turn off direct root login to reduce high-risk exposure
- Limit allowed users and groups in the SSH configuration
- Change the default port to reduce automated scanning
- Use fail2ban or a similar tool to block repeated login attempts
- Keep your system and OpenSSH package updated
Conclusion
This article has shown you how to generate a key pair and use it to access remote servers. This type of authentication not only offers greater security but also eliminates the need to enter a password for each new SSH connection.
References
- RFC Standard No. 4252: “The Secure Shell (SSH) Authentication Protocol”, Internet Engineering Task Force
- ssh.com, SSH Communications Security, Inc.
- SSH - Secure Shell, HTW Chur