SSH Key Generation and Passwordless Login

1. The "Why": How Asymmetric Cryptography Secures SSH

SSH key-based authentication uses a concept called asymmetric cryptography, or public-key cryptography. Instead of a single shared secret (a password), you generate a key pair consisting of two mathematically linked keys:

• A Private Key: This key is your secret. It stays on your client machine and should never be shared. It is the proof of your identity.
• A Public Key: This key is designed to be shared. You place it on any server you want to access.

When you try to connect, the server uses your public key to issue a "challenge" — a message encrypted in a way that only your private key can decrypt. Your SSH client uses your private key to solve this challenge and sends the correct response back to the server. If the response is valid, the server grants you access. This all happens automatically in seconds.

This method is superior to passwords because:

1. Complexity: The keys are far too complex to be guessed by brute force.
2. No Secret Transmission: Your private key (the secret) never travels over the network.

For a more detailed technical explanation, the ArchWiki provides an excellent summary. As an Arch user, you'll find it a valuable and familiar resource.

2. Generating Your SSH Key Pair

Now for the practical part. We'll generate our own key pair using the ssh-keygen command on your local machine.

Choosing a Key Type

Modern SSH supports several types of keys. While RSA is a long-standing default, the current best practice is to use Ed25519. It offers stronger security with a smaller key size, making it faster and more efficient. We will use this type.

The ssh-keygen Command

Open your terminal and run the following command:

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

• -t ed25519: Specifies the key type we want to create.
• -C "...": Adds an optional comment, usually your email or another identifier, to make it easier to track which key is which.

The command will then ask you two questions:

1. File location: Enter file in which to save the key...
   • It's highly recommended to accept the default location (~/.ssh/id_ed25519) by pressing Enter. SSH clients automatically look for keys in this directory.
2. Passphrase: Enter passphrase (empty for no passphrase):
   • This is a crucial security step. The passphrase encrypts your private key file on your computer. If someone were to steal your laptop or gain access to your files, they still wouldn't be able to use your SSH key without knowing its passphrase. Always set a strong passphrase.

The following video provides a clear, step-by-step demonstration of this entire process.

3. Placing Your Public Key on the Server

With your key pair generated, the next step is to copy your public key to the target server. The server needs this key to issue the authentication challenge.

The standard location for public keys on a Linux server is inside the file ~/.ssh/authorized_keys. Each key is on its own line. While you can do this manually, there is a much safer and easier way.

The Easy Way: ssh-copy-id

The ssh-copy-id utility is designed specifically for this task. It connects to the server using the password you used in the last lesson, and automatically handles creating the ~/.ssh directory, creating the authorized_keys file, appending your public key to it, and setting the correct, secure file permissions.

The syntax is:

ssh-copy-id username@remote_host

If you created your key in a non-default location or have multiple keys, you can specify which one to copy with the -i flag:
ssh-copy-id -i ~/.ssh/id_ed25519.pub username@remote_host

The video below demonstrates this command in action.

Understanding the Manual Method

For your own deeper understanding, it's useful to know what ssh-copy-id does behind the scenes. The manual process involves:

1. Copying the public key file (e.g., id_ed25519.pub) to the server.
2. Logging into the server.
3. Appending the content of the public key file to ~/.ssh/authorized_keys.
4. Crucially, setting the correct permissions. Incorrect permissions will cause SSH to reject the key for security reasons.
   • The ~/.ssh directory must be 700 (only the owner can read, write, and execute).
   • The ~/.ssh/authorized_keys file must be 600 (only the owner can read and write).

This ArchWiki section details both the ssh-copy-id command and the manual steps, including the necessary permission changes.

Practice: Configure Passwordless Access

It's time to apply this to your virtual lab.

1. Generate Key: On your Arch Linux machine, run ssh-keygen -t ed25519 and provide a strong passphrase.
2. Copy Key: Use ssh-copy-id to copy your new public key to your Metasploitable2 VM. The command will be:

   ssh-copy-id msfadmin@<IP_OF_METASPLOITABLE>
   

   You will be prompted for the msfadmin password. This should be the last time you need it.
3. Test Connection: Now, try to log in again:

   ssh msfadmin@<IP_OF_METASPLOITABLE>
   

   This time, instead of asking for the server password, it should prompt you for your key's passphrase. After you enter it, you should be logged in.

4. For Ultimate Convenience: ssh-agent

You might be thinking, "I still have to type a passphrase, so it's not truly passwordless." This is where the ssh-agent comes in. It's a background program that securely caches your decrypted private key in memory for the duration of your terminal session.

You only need to unlock your key once with its passphrase, and the agent handles providing it to ssh for all subsequent connections.

Here's the workflow:

1. Start the agent: The command is a bit unusual because it needs to set environment variables for your current shell.

   eval $(ssh-agent)
   

2. Add your key to the agent:

   ssh-add ~/.ssh/id_ed25519
   

   This command will prompt you for your key's passphrase. Once entered, the key is "unlocked" and cached by the agent.
3. Connect: Now, any ssh command will automatically and seamlessly use the key from the agent, with no further prompts.

Note: On most modern desktop environments, an SSH agent is often started automatically when you log in, so you may only need to run ssh-add once per session.

Conclusion

Congratulations! You have now mastered a core security practice for remote administration. You've moved beyond simple passwords to a cryptographically secure method of authentication that is both more secure and, with ssh-agent, more convenient.

Key Takeaways:

• SSH keys work in pairs: a private key that you keep secret and a public key that you share with servers.
• The modern, recommended key type is Ed25519, which you generate with ssh-keygen -t ed25519.
• Always protect your private key file with a strong passphrase.
• ssh-copy-id is the standard tool to safely install your public key on a remote server.
• Incorrect file permissions on the server (~/.ssh and ~/.ssh/authorized_keys) are a common cause of key authentication failure.
• ssh-agent and ssh-add provide convenience by caching your unlocked key in memory.

Next Lesson Preview:
Now that we've hardened our method for logging into the server, the next logical step is to control who can even attempt to connect. In our next lesson, we will begin exploring the first line of defense at the network level: firewalls. You'll learn what a firewall is, the difference between stateless and stateful inspection, and how they are used to protect servers.