Sign In
Sign In

How to Use ssh-agent to Manage Private Keys

How to Use ssh-agent to Manage Private Keys
Adnene Mabrouk
Technical writer
SSH
18.10.2024
Reading time: 4 min

When connecting to remote servers using SSH, users typically authenticate themselves using a pair of cryptographic keys: a public key and a private key. While storing the private key on your local machine, it’s essential to keep it secure with a passphrase. However, entering the passphrase repeatedly can become tedious. Enter ssh-agent, a tool designed to manage and cache your private keys in memory, making SSH connections more efficient and secure.

Why Use ssh-agent for Private Key Management?

SSH private keys provide a secure method of authentication. However, without proper management, frequent SSH operations can require multiple passphrase inputs, especially if you use several private keys. ssh-agent simplifies this process by keeping private keys cached in memory. Once a key is loaded into the agent, it can be used for multiple connections without requiring the passphrase each time. This increases productivity without sacrificing security.

How Does ssh-agent Work?

ssh-agent acts as a background process that stores your private keys and offers them to SSH clients when authentication is required. It caches the passphrase-unlocked private keys in memory so that you don’t have to re-enter the passphrase each time you connect to a server. The agent manages a secure channel between SSH clients and the private keys, ensuring that the private key itself never leaves the local machine.

Setting Up ssh-agent on Linux/MacOS

Linux and macOS both come with ssh-agent pre-installed, making the setup process relatively simple. Here’s a basic outline to start using ssh-agent:

  1. Open a terminal.

  2. Verify ssh-agent is installed by running:

ssh-agent

Image1

If ssh-agent is not installed, it can be added through package managers such as apt for Linux distributions or Homebrew for macOS.

Starting and Configuring ssh-agent

To manually start ssh-agent, use the following command:

eval $(ssh-agent)

This starts the ssh-agent process and configures your shell environment to communicate with the agent.

Adding Private Keys to ssh-agent

Once ssh-agent is running, private keys can be added to it using the ssh-add command:

ssh-add /path/to/private_key

This will prompt you to enter the private key’s passphrase (if it’s protected), and ssh-agent will store the unlocked key in memory for future use.

Checking Loaded Keys in ssh-agent

To verify which keys are currently loaded into ssh-agent, you can use the following command:

ssh-add -l

This command will list the fingerprints of all the currently cached private keys.

Removing Private Keys from ssh-agent

If you want to remove a key from the agent, you can use the -d option with ssh-add:

ssh-add -d ~/.ssh/id_rsa

To remove all keys at once:

ssh-add -D

Automating ssh-agent Start with Shell Configuration

To make sure ssh-agent starts automatically every time you open a new shell session, you can add the following to your .bashrc file:

if ! pgrep -u "$USER" ssh-agent > /dev/null; then
  eval $(ssh-agent -s)
fi

This ensures that ssh-agent is available without requiring manual start every time you open a new terminal.

Common ssh-agent Commands and Usage

  • Start ssh-agent:

eval $(ssh-agent)
  • Add a key to ssh-agent:

ssh-add /path/to/private_key
  • List loaded keys:

ssh-add -l
  • Remove a specific key:

ssh-add -d /path/to/private_key
  • Remove all keys:

ssh-add -D

Security Considerations

While ssh-agent provides convenience by keeping your private keys in memory, it’s crucial to be aware of potential security risks. The agent keeps keys in volatile memory, which can be exploited if your machine is compromised. Some best practices include:

  • Only keep private keys in memory for the duration they are needed.

  • Use strong passphrases for your private keys.

  • Lock the agent when not in use, especially on shared or insecure systems.

  • Use hardware security modules (HSMs) for storing keys when possible.

Conclusion

Using ssh-agent to manage SSH private keys significantly enhances convenience and efficiency while maintaining security. By caching your private keys, ssh-agent allows for quick SSH access without repeated passphrase prompts. However, security best practices should always be followed to ensure that sensitive information remains protected during use. Setting up ssh-agent on Linux and macOS is straightforward, and with proper automation, it can become an indispensable tool for anyone managing secure connections across multiple systems.

SSH
18.10.2024
Reading time: 4 min

Similar

SSH

How to Connect to a Server via SSH: A Step-by-Step Guide

SSH, an application layer protocol, is commonly used for remote access. In this article, we will explore using the SSH protocol to connect to remote Linux servers and configure specific settings to enhance security. SSH can be used with any Linux distribution since it is enabled by default on most modern Unix and Linux distributions. In this guide, we tested everything on Ubuntu 22.04; however, you can also apply it to other distributions like Debian, CentOS, etc. Methods for Connecting via SSH You can use various client programs to connect to Linux servers via SSH. Some popular ones include: Windows: PuTTY, Bitvise SSH Client, SuperPuTTY, mRemoteNG, MobaXterm. macOS: Termius or the built-in SSH utility in Terminal. Windows (Windows 10, Windows 11, Windows Server 2019): The built-in OpenSSH client, accessible through the command line (cmd) or PowerShell. SSH Command Syntax The standard SSH command syntax is as follows: ssh <username@IP_or_domain> For example: ssh [email protected] By default, SSH connects via port 22. If the server uses a different port, specify it using the -p option: ssh [email protected] -p 2222 SSH Server Configuration File The SSH server configuration file is called sshd_config and is located in the /etc/ssh directory. Don't confuse it with the SSH client file ssh_config. In this article, we will focus only on the server file. SSH Password Authentication By default, SSH connections are password-based unless an SSH key was added during server creation (we'll discuss SSH keys in the next section). In most Linux/Unix distributions, the server's configuration includes PAM authentication, allowing users with system accounts to log in using their username and password. To log in using a password, you need the remote server's address and the user's credentials. For example: ssh [email protected] After entering the command, you'll be prompted for the password. If it's correct, you'll access the server. When connecting for the first time, you'll see a message about the server's "fingerprint." Enter yes to proceed. Although password authentication works, it is not the safest method, as passwords can be guessed. A more secure alternative is using SSH keys, discussed in the next section. SSH Keys Authentication SSH keys are a more secure and common method of authentication than passwords. SSH uses two types of keys: Public key: Used for encryption and can be shared publicly. Private key: Used for decryption and should be kept private. To generate SSH keys, use the command: ssh-keygen This command will prompt you to choose a directory to save the keys. By default, they are stored in the .ssh directory in your home folder. For example, in /home/alex/.ssh. You can also set a different location if needed. Press Enter to use the default path. Next, you'll be asked to create a passphrase for added security. If you prefer not to use a passphrase, press Enter when prompted. Once the keys are generated, the private key (id_rsa) and the public key (id_rsa.pub) will be stored in the .ssh directory. Before connecting to a remote host, copy the public key to that host using the ssh-copy-id command: ssh-copy-id -i /home/alex/.ssh/id_rsa.pub [email protected] You'll be prompted to enter the remote user's password once. After that, the public key will be added to the remote host, allowing you to log in without a password: ssh [email protected] If no password is requested, key-based authentication is working correctly. Disabling Password Authentication Since passwords are not secure, disabling password authentication and using only key-based access is recommended. To do this, edit the SSH server configuration file: sudo nano /etc/ssh/sshd_config Find the line PasswordAuthentication and change its value to no: PasswordAuthentication no Save the changes, then restart the SSH server: sudo systemctl restart ssh Before disabling password authentication, ensure that key-based authentication is working. If not, you may lock yourself out of the server. If this happens, you can restore password authentication via the server's web console. Changing the Default SSH Port By default, the SSH server uses port 22. You can change this by editing the sshd_config file. Find the Port line, uncomment it (remove the # symbol), and specify a new port (between 1024 and 65535): Port 2224 After saving the changes, restart the SSH server: sudo systemctl restart ssh To connect to the server on the new port, use the -p option: ssh [email protected] -p 2224 Disabling Root Login In some distributions, root login is allowed by default. Since the root user has full system privileges, it's safer to disable root login. To do this, find the line PermitRootLogin in the sshd_config file and set it to no: PermitRootLogin no Save the file and restart the SSH server: sudo systemctl restart ssh Allowing or Denying Specific Users You can restrict SSH access to specific users by editing the sshd_config file with the following parameters: AllowUsers: Specify which users are allowed to connect via SSH. For example: AllowUsers test admin DenyUsers: Specify users who are denied SSH access. For example: DenyUsers nginx websrv To apply changes, restart the SSH server: sudo systemctl restart ssh Conclusion SSH is an indispensable tool for connecting to remote servers. In addition to built-in encryption, you can further secure your SSH server by configuring it properly, such as disabling password authentication and limiting access to specific users.
16 September 2024 · 5 min to read

Do you have questions,
comments, or concerns?

Our professionals are available to assist you at any moment,
whether you need help or are just unsure of where to start.
Email us
Hostman's Support