How to Generate and Secure SSH Keys for Remote Access

Secure Shell (SSH) is the standard way to connect to remote servers. If you still use passwords for daily access, SSH keys give you stronger authentication and remove the risk of password guessing against that account.

This guide shows you how to generate SSH keys, protect the private key with a passphrase, install the public key on a server, and use ssh-agent so you do not type the passphrase on every connection.

Understanding SSH Key Pairs

An SSH key pair consists of two distinct components:

The Private Key: This key must never be shared. It stays securely on your local machine and is used to prove your identity to the remote server.
The Public Key: This key is freely shared and uploaded to the ~/.ssh/authorized_keys file on the remote server(s) you wish to access. The server uses this key to verify the signature generated by your private key.

Choosing the Right Algorithm

When generating keys, choose a modern algorithm. Ed25519 is a good default for current OpenSSH clients because it is fast, compact, and widely supported. RSA still works and is useful when you must connect to older systems that do not support Ed25519.

Step 1: Generating the SSH Key Pair

The ssh-keygen utility is the standard tool for creating SSH key pairs on Linux, macOS, and Windows (via Git Bash or WSL).

Generating an Ed25519 Key (Recommended)

To create a modern Ed25519 key, use the following command. We specify the key type (-t ed25519) and provide a comment (-C) to help identify the key's purpose or owner:

ssh-keygen -t ed25519 -C "[email protected]_or_host_name"

When prompted:

Enter file in which to save the key: Press Enter to accept the default location (/home/user/.ssh/id_ed25519).
Enter passphrase (recommended): Set a strong passphrase for keys used outside disposable lab systems. This encrypts your private key, so a stolen key file is not immediately usable.

Generating an RSA Key (Alternative)

If compatibility with very old systems is required, you can generate an RSA key, ensuring you specify a sufficient key length (at least 4096 bits):

ssh-keygen -t rsa -b 4096 -C "your_rsa_key_comment"

Key Output Files

After generation, two files are created in your ~/.ssh/ directory (assuming defaults):

id_ed25519 (or id_rsa): Your Private Key
id_ed25519.pub (or id_rsa.pub): Your Public Key

Security best practice: Never share the file without the .pub extension. Set restrictive permissions on your private key with chmod 600 ~/.ssh/id_ed25519.

Step 2: Copying the Public Key to the Server

The remote server must have your public key in its ~/.ssh/authorized_keys file to grant access.

Using `ssh-copy-id` (The Easiest Method)

The ssh-copy-id utility automates the process, handling directory creation and permission settings on the remote server. You will need to authenticate with a password one last time for this initial setup.

ssh-copy-id user@remote_host_ip

If successful, the command will inform you that the keys have been added. You can now attempt to log in.

Manual Copy (If `ssh-copy-id` is Unavailable)

If you cannot use ssh-copy-id, you can manually append the public key content. First, display the public key:

cat ~/.ssh/id_ed25519.pub

Then, log into the remote server using your password and append the output to the authorized_keys file:

# On the remote server
mkdir -p ~/.ssh
chmod 700 ~/.ssh
# Replace <PASTE_YOUR_PUBLIC_KEY_HERE> with the actual key content
echo "<PASTE_YOUR_PUBLIC_KEY_HERE>" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Step 3: Securing Access with `ssh-agent`

Typing your passphrase every time you connect to a server becomes tedious. The ssh-agent is a background program that securely holds your decrypted private keys in memory, allowing you to use them without repeatedly entering the passphrase.

Starting and Using `ssh-agent`

Ensure the agent is running: On most modern Linux/macOS systems, the agent starts automatically when you log in. You can check its status by looking for the environment variables:
```
echo $SSH_AUTH_SOCK
```

Add your key to the agent: Use the ssh-add command to load your private key. You will be prompted for the passphrase only once.

ssh-add ~/.ssh/id_ed25519
# Enter passphrase for /home/user/.ssh/id_ed25519: **********
# Identity added: /home/user/.ssh/id_ed25519 (comment)

Verify loaded keys:
```
ssh-add -l
```

Now, when you run ssh user@remote_host_ip, the connection will authenticate using the key held by the agent without asking for the passphrase again (until the agent session ends).

Important `ssh-agent` Notes

Session Dependent: The keys loaded into the agent are typically only available for the current terminal session or desktop login session. You will need to re-run ssh-add after logging out and back in.
Key Lifetime: You can set a maximum lifetime for keys held in the agent using the -t flag (e.g., ssh-add -t 1h ~/.ssh/id_ed25519 keeps the key loaded for one hour).

Advanced Security: Disabling Password Authentication

Once you have confirmed that key-based authentication works flawlessly across all required servers, the strongest security measure is to disable password-based logins entirely. This prevents brute-force attacks against passwords.

Connect to your server via SSH using your key.
Edit the SSH daemon configuration file, usually located at /etc/ssh/sshd_config:
```
sudo nano /etc/ssh/sshd_config
```

Find and set the following directives:

# Ensure this is set to yes (usually default)
PubkeyAuthentication yes

# Disable password logins
PasswordAuthentication no

Check the configuration before restarting:
```
sudo sshd -t
```
Restart the SSH service to apply changes. The service name is commonly sshd on RHEL-family systems and ssh on Debian/Ubuntu:
```
sudo systemctl restart sshd
# or
sudo systemctl restart ssh
```

Warning: Before disabling password authentication, keep one working SSH session open and confirm a second login works with the new key. If the restart fails or the key is wrong, you will need console or out-of-band access.

Next Steps

After your first key-based login works, treat SSH keys like production credentials:

Generate a unique key pair for every major system or service you access.
Regularly audit the authorized_keys file on critical servers.
Remove old keys when people change roles or machines are retired.
Use ssh-add -t for short-lived agent sessions on shared workstations.