Learn › Linux for Production Support › Kiran secures access with SSH keys

Linux for Production Support Ch 19 / 32 Intermediate

🔑

Kiran secures access with SSH keys

SSH key authentication, config shortcuts, tunnelling and remote execution

⏱ 12 min 6 commands 5 takeaways

🔑

In this chapter

Kiran

DevOps engineer, 20-server infrastructure

The story

Kiran was the new DevOps engineer responsible for setting up secure access to 20 production servers. The old way: manually distributing passwords, employees writing them in Notepad. The new way: SSH keys, proper configuration, and access that can be revoked instantly.

SSH KEY AUTHENTICATION — NO MORE PASSWORDS

SSH key authentication works like a padlock and key. You create a key pair: a private key (stays on your machine, never shared) and a public key (goes on the server). When you connect, the server checks if your private key matches the public key it has on file. No password transmitted. Cannot be brute-forced.

# Step 1: Generate a key pair (on YOUR machine, do this once)
ssh-keygen -t ed25519 -C "kiran@company.com"
# Saves private key to ~/.ssh/id_ed25519
# Saves public key to ~/.ssh/id_ed25519.pub

# Step 2: Copy your public key to the server
ssh-copy-id kiran@prod-server-01
# This appends your public key to ~/.ssh/authorized_keys on the server

# Step 3: Now connect without password
ssh kiran@prod-server-01

# Check what keys are authorised on a server:
cat ~/.ssh/authorized_keys

SSH CONFIG — SHORTCUTS FOR EVERY SERVER

Instead of typing ssh kiran@10.0.0.5 -p 2222 -i ~/.ssh/special_key every time:

nano ~/.ssh/config

Host prod-pay
    HostName 10.0.0.5
    User kiran
    Port 2222
    IdentityFile ~/.ssh/prod_key

Host prod-db
    HostName 10.0.0.6
    User kiran
    IdentityFile ~/.ssh/prod_key

Host prod-*
    User kiran
    StrictHostKeyChecking yes
    ServerAliveInterval 60

# Now just type:
ssh prod-pay
ssh prod-db

SECURE THE SSH SERVER

sudo nano /etc/ssh/sshd_config

# Key settings to change:
PermitRootLogin no              # NEVER allow root login over SSH
PasswordAuthentication no       # key only, no passwords (after copying your key!)
MaxAuthTries 3                  # block after 3 failed attempts
AllowUsers kiran vijay priya    # whitelist — only these users can SSH in
Port 2222                       # change from default 22 (reduces bot noise)
ClientAliveInterval 300         # disconnect idle sessions after 5 minutes
ClientAliveCountMax 2

# Apply changes:
sudo sshd -t                    # test config before reloading (like nginx -t)
sudo systemctl reload sshd

TRANSFERRING FILES OVER SSH

# Copy a file from local to server:
scp local_file.txt kiran@prod-server-01:/opt/app/config/

# Copy a file from server to local:
scp kiran@prod-server-01:/var/log/app.log ./

# Copy an entire directory:
scp -r /local/dir/ kiran@prod-server-01:/remote/dir/

# rsync: smarter copy (only transfers changed files):
rsync -avz /local/dir/ kiran@prod-server-01:/remote/dir/
rsync -avz --delete /local/dir/ kiran@prod-server-01:/remote/dir/   # mirror exactly

SSH TUNNELLING — ACCESS THINGS BEHIND FIREWALLS

The database server only accepts connections from the app server, not your laptop. SSH tunnelling solves this:

# Forward local port 5433 to the database server through the app server:
ssh -L 5433:db-server:5432 kiran@app-server

# Now on your laptop, connect to localhost:5433 and it reaches db-server:5432
psql -h localhost -p 5433 -U appuser mydb

# Access a web app running on a server with no public port:
ssh -L 8080:localhost:8080 kiran@prod-server-01
# Open http://localhost:8080 on your laptop — it goes through the tunnel

RUN COMMANDS ON MULTIPLE SERVERS AT ONCE

# Check uptime on all servers:
for server in prod-{01..10}; do
    echo "=== $server ===";
    ssh kiran@$server 'uptime' 2>/dev/null;
done

# Copy the same config file to all servers:
for server in prod-{01..10}; do
    scp app.conf kiran@$server:/etc/myapp/app.conf
done

# Parallel with xargs (20 servers at once):
echo prod-{01..10} | tr ' ' '\n' | xargs -P 10 -I{} ssh kiran@{} 'df -h'

Kiran set up key-based authentication for all 20 servers in one afternoon. The next time an employee left the company, revoking their access meant deleting one line from authorized_keys on each server — 2 minutes, not 2 hours.

Key takeaways

SSH key authentication is more secure than passwords — private key stays on your machine, public key goes on server

~/.ssh/config lets you define aliases for servers — ssh prod-pay instead of ssh -i key -p 2222 user@10.0.0.5

PermitRootLogin no and PasswordAuthentication no in sshd_config are the two most important security settings

SSH tunnelling forwards a local port through an SSH connection — access databases and internal tools securely

rsync --delete mirrors a directory exactly — only transfers changed files, much faster than scp for large directories

Commands from this chapter

$ ssh-keygen -t ed25519 -C 'you@company.com'

Generate an SSH key pair (run once on your local machine)

$ ssh-copy-id username@server

Copy your public key to a server — enables passwordless login

$ ssh -L 5433:db-server:5432 user@app-server

Tunnel local port 5433 to database through app server

$ rsync -avz /local/dir/ user@server:/remote/dir/

Sync directory to server, only transferring changed files

$ sudo sshd -t

Test sshd config for syntax errors before reloading (like nginx -t)

$ for s in prod-{01..10}; do ssh $s 'uptime'; done

Run a command on 10 servers sequentially