Mastering SSH-keygen: A Critical Guide to Passwordless Login

Secure Shell (SSH) is the bedrock of secure remote administration on Linux systems. While password-based authentication is common, it carries inherent vulnerabilities. SSH key-based authentication offers a superior, more secure, and convenient alternative, enabling passwordless logins. This guide meticulously details the process of generating, managing, and utilizing SSH key pairs with the ssh-keygen utility, ensuring robust server access without compromising security.

Prerequisites

• Access to a Linux/Unix-like operating system or macOS.
• Basic familiarity with the command-line interface (CLI).
• A remote server to which you wish to establish passwordless access.

Step 1: Understand SSH Key Fundamentals

Before generation, grasp the core concept: SSH key authentication relies on a cryptographic key pair. This pair consists of a private key and a public key.

• Private Key: This key resides on your local machine and must be kept absolutely secret. It is analogous to a very complex, unguessable password.
• Public Key: This key is placed on the remote server you wish to access. It acts as a digital lock that only your corresponding private key can open.

Pro-Tip: The Importance of Secrecy

The private key is the ultimate credential. Its compromise grants unauthorized access to all systems where its public counterpart is installed. Never share your private key, and protect it with a strong passphrase during generation.

Step 2: Generate a New SSH Key Pair

Initiate the key generation process using the ssh-keygen command. While RSA is still widely used, newer algorithms like Ed25519 offer superior security and performance. For general compatibility and strong security, we’ll use RSA with a robust key length.

ssh-keygen -t rsa -b 4096

• -t rsa: Specifies the key type as RSA.
• -b 4096: Sets the key length to 4096 bits, a highly recommended secure length.

The command will prompt you for two critical pieces of information:

1. File to save the key: The default location (~/.ssh/id_rsa) is standard and generally recommended. Press Enter to accept it. If you generate multiple keys, specify a different name (e.g., ~/.ssh/id_rsa_myserver).
2. Passphrase: This is an encryption layer for your private key. It’s a critical security measure, especially if your local machine is ever compromised. Choose a strong, memorable passphrase. While optional, omitting it is a significant security risk.

Example Output:

Generating public/private rsa key pair.
Enter file in which to save the key (~/.ssh/id_rsa): [Press Enter]
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/youruser/.ssh/id_rsa.
Your public key has been saved in /home/youruser/.ssh/id_rsa.pub.
The key fingerprint is: SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx youruser@yourlocalmachine
The key's randomart image is: ...

Step 3: Examine the Generated Keys and Permissions

Once generated, the keys are stored in your ~/.ssh/ directory. It’s imperative to verify their presence and, more critically, their permissions.

ls -l ~/.ssh/

You should see two new files:

• id_rsa: Your private key.
• id_rsa.pub: Your public key.

Critical Permission Check

SSH requires strict permissions for your private key. If they are too permissive, SSH will refuse to use the key. The private key (id_rsa) should have permissions of 600 (read/write only for the owner).

ls -la ~/.ssh/id_rsa

If the permissions are not -rw-------, rectify them immediately:

chmod 600 ~/.ssh/id_rsa

The public key (id_rsa.pub) can have more relaxed permissions, typically 644, but 600 also works.

Step 4: Copy the Public Key to a Remote Server

To enable passwordless login, your public key must be placed in the ~/.ssh/authorized_keys file on the remote server.

Method 1: Using ssh-copy-id (Recommended)

This utility automates the process, creating the .ssh directory and authorized_keys file with correct permissions if they don’t exist.

ssh-copy-id user@remote_host_ip_or_hostname

You will be prompted for the remote server’s password (the last time you’ll need it for this user/key pair). After successful authentication, your public key will be appended to ~/.ssh/authorized_keys on the remote server.

Method 2: Manual Copy (If ssh-copy-id is unavailable)

If ssh-copy-id is not present, you can manually copy the public key. This requires establishing a traditional password-based SSH connection first.

cat ~/.ssh/id_rsa.pub | ssh user@remote_host_ip_or_hostname "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

This command does the following:

• Reads your local public key.
• Establishes an SSH connection to the remote server.
• Creates the ~/.ssh directory if it doesn’t exist and sets its permissions to 700.
• Appends your public key to ~/.ssh/authorized_keys.
• Sets the permissions of authorized_keys to 600.

Pro-Tip: Remote Server Permissions

Just as on your local machine, the ~/.ssh directory on the remote server must have 700 permissions, and the ~/.ssh/authorized_keys file must have 600 permissions. SSH will reject keys if these are incorrect.

Step 5: Authenticate Without a Password

With the public key successfully deployed, you can now attempt to log in to the remote server using your SSH key.

ssh user@remote_host_ip_or_hostname

If you set a passphrase during key generation, you will be prompted to enter it. If no passphrase was set, you should be logged in directly without any password prompt.

Practical Tip: SSH Agent for Passphrase Management

Constantly entering your passphrase can be tedious. The ssh-agent utility can securely store your decrypted private key in memory for the duration of your session, allowing passwordless access after entering the passphrase just once.

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

You’ll be prompted for your passphrase once by ssh-add. Afterward, any subsequent SSH connections using that key will not require the passphrase until your session ends or the agent is killed.

Next Steps

Consider generating multiple key pairs for different servers or purposes, managing them with an ~/.ssh/config file to define custom connection settings and specific key paths for hosts. Regularly review and revoke any compromised or unused keys to maintain a secure posture.