SSH Authentication & Configuration

Understanding SSH keys and config files - how to manage multiple servers without typing passwords constantly.

The Problem

When managing a homelab with multiple machines (Raspberry Pi, Thinkcentre, MacBook Pro, etc.), you'll SSH into them constantly. Without proper setup, every connection requires:

Typing the full command: ssh username@192.168.68.58
Typing your password
Remembering all the IP addresses

This gets old fast.

The Two-Part Solution

Part 1: SSH Config File (Shortcuts)

The ~/.ssh/config file lets you create memorable shortcuts for your machines.

Location: ~/.ssh/config

Example:

# Homelab Machines
Host pi
    HostName 192.168.68.58
    User ashish

Host thinkcentre
    HostName 192.168.68.61
    User ashish

Host nas
    HostName 192.168.68.62
    User ashish

Before:

ssh ashish@192.168.68.58

After:

ssh pi

Just saves typing. You still need a password.

Part 2: SSH Key Authentication (Passwordless Login)

SSH keys let you authenticate without typing passwords.

How SSH Keys Work

┌─────────────────────────────────────────────────────────────────┐
│  SSH KEY AUTHENTICATION                                         │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ONE-TIME SETUP:                                                │
│  ──────────────                                                 │
│                                                                 │
│  1. Your computer has a "key pair":                             │
│     • Private key: ~/.ssh/id_ed25519 (NEVER share this)        │
│     • Public key:  ~/.ssh/id_ed25519.pub (safe to share)       │
│                                                                 │
│     Think of it like a lock and key:                            │
│     - Private key = your physical key (keep it safe!)           │
│     - Public key = the lock (can install on any door)           │
│                                                                 │
│  2. Copy the PUBLIC key to remote server:                       │
│     The public key goes into: ~/.ssh/authorized_keys            │
│                                                                 │
│  AFTER SETUP (every SSH connection):                            │
│  ─────────────────────────────────────                          │
│                                                                 │
│  You: ssh pi                                                    │
│  Your Mac: "Here's proof I have the private key"                │
│  Pi:  "I recognize that key in my authorized_keys file!"        │
│       ✅ Logged in, no password needed                          │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

The Cryptographic Handshake

When you SSH with keys:

You initiate connection: ssh pi
Server sends challenge: "Prove you have the private key"
Your computer responds: Signs the challenge with private key
Server verifies: Uses your public key to verify the signature
Access granted if verification succeeds

Security: Even if someone intercepts the traffic, they can't derive your private key from the exchange. This is why SSH keys are more secure than passwords.

Setting Up SSH Keys

Step 1: Generate a Key Pair (if you don't have one)

# Generate an ED25519 key (modern, secure, small)
ssh-keygen -t ed25519 -C "your-email@example.com"

# Press Enter for default location (~/.ssh/id_ed25519)
# Optional: Set a passphrase (protects key if laptop is stolen)

What gets created:

~/.ssh/id_ed25519 - Your private key (NEVER share)
~/.ssh/id_ed25519.pub - Your public key (safe to share)

Step 2: Copy Public Key to Remote Server

Easy way (using ssh-copy-id):

ssh-copy-id username@remote-server

# Example:
ssh-copy-id ashish@192.168.68.58

This will:

Ask for your password (ONE TIME)
Copy your public key to ~/.ssh/authorized_keys on the remote server
Set correct permissions

Manual way (if ssh-copy-id isn't available):

# On your local machine:
cat ~/.ssh/id_ed25519.pub

# Copy the output, then SSH to remote server:
ssh username@remote-server

# On remote server:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "PASTE_YOUR_PUBLIC_KEY_HERE" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
exit

Step 3: Test It

ssh username@remote-server

# Should log in without asking for password!

Troubleshooting SSH Keys

"Permission denied" after setting up keys

Check permissions on remote server:

# On the remote server:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Check SSH server config:

# On remote server:
sudo nano /etc/ssh/sshd_config

# Ensure these are set:
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# Restart SSH:
sudo systemctl restart ssh

"Too many authentication failures"

Your SSH client is trying all your keys before asking for password.

Workaround:

ssh -o PubkeyAuthentication=no username@server
# This forces password authentication

Verify which key is being used

ssh -v username@server

# Look for lines like:
# "Offering public key: /Users/you/.ssh/id_ed25519"
# "Server accepts key: pkalg ssh-ed25519"

Advanced SSH Config

Your ~/.ssh/config can do much more:

# Multiple machines with same username
Host pi thinkcentre nas
    User ashish

Host pi
    HostName 192.168.68.58

Host thinkcentre
    HostName 192.168.68.61

Host nas
    HostName 192.168.68.62

# Keep connections alive
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

# Use specific key for work servers
Host work-*
    IdentityFile ~/.ssh/work_key
    User work-username

# Jump through bastion host
Host internal-server
    HostName 10.0.1.50
    ProxyJump bastion.company.com

Security Best Practices

Practice	Why
Use ED25519 keys	Modern, secure, faster than RSA
Set a passphrase	Protects your key if laptop is stolen
Never share private key	It's called "private" for a reason
One key per device	If one device is compromised, revoke only that key
Disable password auth	After keys work, disable password login on servers

Disable Password Authentication (Advanced)

Once SSH keys work on all your machines:

# On remote server:
sudo nano /etc/ssh/sshd_config

# Change this:
PasswordAuthentication no

# Restart SSH:
sudo systemctl restart ssh

Now the server ONLY accepts key-based authentication. Much more secure.

Managing Multiple Keys

If you have different keys for different purposes:

# Work key
ssh-keygen -t ed25519 -f ~/.ssh/work_key -C "work@company.com"

# Personal key
ssh-keygen -t ed25519 -f ~/.ssh/personal_key -C "me@gmail.com"

# GitHub key
ssh-keygen -t ed25519 -f ~/.ssh/github_key -C "github@gmail.com"

Then in ~/.ssh/config:

Host github.com
    IdentityFile ~/.ssh/github_key

Host work-*
    IdentityFile ~/.ssh/work_key

Host *
    IdentityFile ~/.ssh/personal_key

Quick Reference

Task	Command
Generate key	`ssh-keygen -t ed25519`
Copy key to server	`ssh-copy-id user@server`
View public key	`cat ~/.ssh/id_ed25519.pub`
Test connection	`ssh -v user@server`
Check key permissions	`ls -la ~/.ssh/`
Remove host from known_hosts	`ssh-keygen -R hostname`
Add key to ssh-agent	`ssh-add ~/.ssh/id_ed25519`

Why This Matters for Homelab

When you're managing 4+ servers:

Without SSH keys:

Type password 20+ times per day
Annoying, slow, breaks flow

With SSH keys + config:

ssh pi         # Instant login
ssh nas        # Instant login
ssh thinkcentre # Instant login

You can also:

Run commands without interactive login: ssh pi "sudo reboot"
Copy files easily: scp file.txt pi:/home/ashish/
Script automation without storing passwords

This is foundational infrastructure knowledge. Every DevOps engineer, SRE, and systems administrator uses SSH keys daily.

Next Steps

Set up SSH keys between your Mac and all homelab machines
Create ~/.ssh/config with shortcuts for all machines
Test passwordless login to each machine
Document your SSH setup in your homelab changelog
Write a blog post: "SSH Keys: Why I Never Type Passwords Anymore"

This is proof-of-work material. Employers want to see you understand secure authentication.