Configuring SSH Key-Based Authentication

🎯 Learning Objective

By the end of this unit, you'll master SSH key generation and deployment for Passwordless authentication, essential skills for automating deployments, managing server access, and maintaining secure infrastructure in DevOps environments.

📚 Concept Introduction

SSH key-based authentication is fundamental to DevOps automation, eliminating password dependencies that break automated workflows and create security vulnerabilities. Production environments rely on SSH keys for CI/CD pipelines, automated deployments, configuration management, and secure team access to distributed infrastructure.

📁 Pre-created:

• Two-node environment (node-01 and node-02) with passwordless SSH currently disabled
• Existing SSH infrastructure for lab access (do not modify existing authorized_keys entries)
• Terminal access to both nodes for hands-on SSH key configuration

🔐 Understanding SSH Key Authentication

◆ The Problem with Password Authentication

Currently, SSH to node-02 will fail because the lab has disabled password authentication:

ssh laborant@node-02

You'll see: Permission denied (publickey,gssapi-keyex,gssapi-with-mic)

This error occurs because node-02 requires SSH key authentication but doesn't trust any keys from node-01 yet.

◆ Lab Environment Note

Lab environment provides two terminal tabs at the top, one for node-01 and one for node-02. You can switch between them to perform the following manual steps.

◆ How SSH Key Authentication Works

SSH keys use public-key cryptography to establish trust between systems:

• Private key - Stays secret on your local system, never shared
• Public key - Can be freely distributed to remote systems
• Authentication - Remote system verifies your identity using the key pair

The trust relationship:

1. You generate a key pair on your local system
2. You place your public key in the remote system's authorized_keys file
3. SSH uses your private key to prove your identity to the remote system

◆ How SSH Automatically Finds Your Keys

Even though we call it "passwordless" SSH, the authentication still happens automatically behind the scenes:

On your local system: SSH automatically looks in your ~/.ssh/ directory for private key files like id_rsa, id_ed25519, etc.

On the remote system: SSH checks if your public key exists in the ~/.ssh/authorized_keys file.

The magic: When you run ssh laborant@node-02, SSH automatically tries your private key from ~/.ssh/id_rsa and the remote system checks if the matching public key is in its authorized_keys file. If they match, you're connected without typing anything.

🔧 SSH Key Generation

◆ Understanding Key Generation

Basic key generation syntax:

ssh-keygen -t rsa -b 4096

Key generation process:

1. Algorithm selection (-t rsa) - RSA is widely supported
2. Key strength (-b 4096) - 4096-bit keys provide strong security
3. File location - Default location is ~/.ssh/id_rsa (private) and ~/.ssh/id_rsa.pub (public)
4. Passphrase decision - Whether to encrypt your private key file

◆ Key Generation Interactive Process

When you run ssh-keygen, you'll see three prompts:

Prompt 1: File location

Enter file in which to save the key (/home/laborant/.ssh/id_rsa): 

Press Enter to use the default location.

Prompt 2: Passphrase

Enter passphrase (empty for no passphrase):

A passphrase encrypts your private key file for extra security, but requires typing it every time you use the key. Press Enter to skip it (suitable for automation and this lab).

Prompt 3: Confirm passphrase

Enter same passphrase again:

Press Enter again to confirm (still empty).

Result: Creates ~/.ssh/id_rsa (private key) and ~/.ssh/id_rsa.pub (public key).

📤 SSH Key Deployment

◆ Understanding Key Deployment

To enable passwordless SSH, your public key must be added to the remote system's authorized_keys file. This file contains all public keys that are trusted for authentication.

The deployment process:

1. View your public key on the local system
2. Copy the public key content to the remote system
3. Append to authorized_keys without overwriting existing entries

◆ Manual Key Deployment Process

Step 1: Display your public key on node-01:shell cat ~/.ssh/id_rsa.pub

This shows a long string starting with ssh-rsa AAAA... - this is your public key.

Step 2: Add the key to node-02's authorized keys:

Switch to node-02 terminal and run: shell echo "PASTE_YOUR_PUBLIC_KEY_HERE" >> ~/.ssh/authorized_keys

Important: Use >> (append) not > (overwrite) to preserve existing lab access keys.

✅ Testing Passwordless Authentication

◆ Verifying the Configuration

After deploying your public key, test the connection:

ssh laborant@node-02

Success indicators:

• No password prompt appears
• Direct connection to node-02
• Command prompt changes to show you're on the remote system

Exit the SSH session:

exit

🔄 Understanding SSH Key Directionality

◆ One-Way Trust Relationship

SSH key authentication is directional. Configuring node-01 → node-02 access does NOT automatically enable node-02 → node-01 access.

Current setup:

• node-01 can SSH to node-02 (you configured this)
• node-02 cannot SSH to node-01 (not configured)

Why this matters in production:

• Role separation - Web servers might access databases, but databases don't need reverse access
• Security isolation - Limits potential attack paths between systems
• Access control - Teams can have different access patterns based on their roles

🚀 Automated Key Deployment

◆ The ssh-copy-id Command

Once you have SSH access to a remote system, ssh-copy-id automates key deployment:

ssh-copy-id laborant@node-02

How ssh-copy-id works:

1. Connects using existing SSH access (password or existing key)
2. Reads your local public key file
3. Appends the key to the remote authorized_keys file safely
4. Sets proper file permissions automatically

Production advantage: Eliminates manual copy-paste errors and ensures proper file permissions.

Note: In this lab, you used manual deployment first because no authentication method was initially available. In production, you often have password access or existing keys to bootstrap the process.

📋 Essential Command Reference

💡 Key Takeaways

• SSH key authentication eliminates passwords and enables DevOps automation workflows
• Key pairs consist of a private key (kept secret) and public key (shared with remote systems)
• Public keys are added to the authorized_keys file on remote systems to establish trust
• SSH key trust is directional - each connection direction must be configured separately
• Manual key deployment teaches the underlying process, while ssh-copy-id automates it safely
• Proper key management enables secure automation, team access control, and infrastructure scaling
• Understanding key concepts enables troubleshooting authentication issues in production environments

Mastering SSH key configuration is essential for implementing secure DevOps automation and managing infrastructure access at scale.