SSH Key Authentication: A Guide to Secure Server Access

Previously in this course, we covered Ownership and Chown: Managing Linux File Access and File Permissions Fundamentals: Decoding Linux Access Controls to secure the files on our system. Now that we understand how Linux governs access, it’s time to secure the gateway to our server: SSH.

Why SSH Keys Matter

Password-based authentication is the weakest link in your Linux server security strategy. Passwords can be guessed, brute-forced, or intercepted.

SSH key authentication uses asymmetric cryptography. You hold a "private key" that never leaves your machine, and you place the corresponding "public key" on the server. When you connect, the server challenges your machine to prove it holds the private key. This process is mathematically impossible to replicate with a password and effectively renders brute-force attacks useless.

Step 1: Generating Your SSH Key Pair

On your local machine, use ssh-keygen to generate a pair. We'll use the Ed25519 algorithm, which is modern, secure, and fast.

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

The terminal will ask you where to save the file. Press Enter to accept the default location (~/.ssh/id_ed25519).

Next, it will prompt for a passphrase. Do not skip this. A passphrase adds a layer of encryption to your private key file itself. If someone steals your laptop, they still can't use your key without that passphrase.

Step 2: Copying the Public Key to the Server

Once generated, your public key is located at ~/.ssh/id_ed25519.pub. You need to authorize this key on your remote server. The easiest way to do this is using ssh-copy-id:

Bash
ssh-copy-id user@your-server-ip

This command logs into your server once (using your password), copies the public key into the ~/.ssh/authorized_keys file, and sets the correct permissions automatically.

If ssh-copy-id isn't available, you can manually append your key:

1. Copy the contents of your local ~/.ssh/id_ed25519.pub.
2. On the server, run mkdir -p ~/.ssh && nano ~/.ssh/authorized_keys.
3. Paste the key on a new line and save.
4. Run chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys to ensure the security of these files.

Step 3: Streamlining Access with SSH Config

Typing ssh user@192.168.1.50 every time is tedious. Create a local config file to simplify your life.

1. Open (or create) ~/.ssh/config on your local machine.
2. Add the following entry:

TEXT
Host web-server
    HostName 192.168.1.50
    User your_username
    IdentityFile ~/.ssh/id_ed25519

Now, you can simply run:

Bash
ssh web-server

Hands-on Exercise

1. Generate an Ed25519 key pair on your local machine.
2. Copy your public key to your project server.
3. Verify you can log in without entering a password.
4. Create an entry in your local ~/.ssh/config file to connect to your server using a custom alias (e.g., web-server).

Common Pitfalls

• Permissions: The SSH daemon is extremely strict. If the permissions on your .ssh directory or authorized_keys file are too "loose" (e.g., group-writable), the server will ignore your keys for security reasons. Always ensure they are 700 and 600 respectively.
• Wrong Key: If you have multiple keys, SSH might try the wrong one. You can force a specific key using ssh -i ~/.ssh/my-key user@host.
• Lost Passphrase: If you lose the passphrase to your private key, there is no "forgot password" button. You will have to delete the key and generate a new one.

FAQ

Recap

We've successfully moved from vulnerable passwords to robust, cryptographic authentication. By generating keys, deploying them to our remote server, and simplifying the connection process with an SSH config file, we've hardened our infrastructure access. This is a foundational step for any DevOps workflow.

Up next: We'll move into system monitoring by learning about processes and how the Linux kernel manages what's running on your server.