treeru.com

Once you manage more than two or three servers, typing passwords becomes a chore. The bigger issue is security — password auth is vulnerable to brute-force attacks, and strong passwords are hard to remember. Switching to SSH key authentication solves both problems at once: stronger security and zero-password convenience.

Ed25519

Recommended Algorithm

256-bit

Key Security Strength

0

Passwords to Type

~/.ssh

Key Storage Location

1Why Key-Based Authentication

AspectPassword AuthKey Auth
Brute-Force AttacksVulnerable (guessable)Impossible without the key
ConvenienceType every timeAutomatic authentication
AutomationHardcoded passwords in scriptsKey-based automation is safe
Multi-ServerRemember a password per serverOne key for all servers
Audit TrailHard to identify who logged inEach key maps to a person

Key Point: The Private Key Never Leaves Your Machine

Key authentication does not transmit the private key to the server. The server sends a challenge, your client signs it with the private key, and sends back the signature. Even if the network is intercepted, the key cannot be extracted.

2Generating and Deploying SSH Keys

Key Generation

# Generate an Ed25519 key (recommended)
ssh-keygen -t ed25519 -C "user@workstation"

# Output:
# Generating public/private ed25519 key pair.
# Enter file in which to save the key (~/.ssh/id_ed25519): [Enter]
# Enter passphrase: [optional — adds an extra security layer]

# Verify the key files
ls -la ~/.ssh/
# id_ed25519       ← Private key (NEVER share this)
# id_ed25519.pub   ← Public key (deploy to servers)

Why Ed25519?

Ed25519 keys are shorter than RSA (256-bit) yet match the security strength of RSA 3072-bit. Signing and verification are also faster. As of 2026, Ed25519 is the de facto standard for new SSH keys.

Key Deployment

# Method 1: ssh-copy-id (easiest)
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@10.x.x.x

# Method 2: Manual copy
cat ~/.ssh/id_ed25519.pub | ssh user@10.x.x.x "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

# Method 3: Deploy to multiple servers at once
for server in server-a server-b server-c; do
  ssh-copy-id -i ~/.ssh/id_ed25519.pub user@$server
done

# Verify (you should connect without a password prompt)
ssh user@10.x.x.x

File Permissions Matter

SSH silently ignores keys if permissions are too loose. Always verify:~/.ssh (700),authorized_keys (600),id_ed25519 (600).

3Disabling Password Authentication

After confirming key-based login works, disable password authentication. Verify key access first — reversing the order locks you out of the server.

# Edit /etc/ssh/sshd_config
sudo nano /etc/ssh/sshd_config

# Change these settings
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes                          # Keep UsePAM yes on Ubuntu/Debian
PubkeyAuthentication yes

# Restart the SSH service
sudo systemctl restart sshd

# IMPORTANT: Keep your current session open.
# Test from a NEW terminal first.
# If something goes wrong, roll back from the existing session.

Lockout Prevention Checklist

  • 1. Confirm key login works (from a new terminal)
  • 2. Never close the current SSH session
  • 3. After editing sshd_config, test from a new session
  • 4. If something breaks, revert from the existing session
  • 5. Have out-of-band access ready (IPMI, physical console)

4Managing Aliases with SSH Config

With many servers, typing IP addresses, ports, and usernames gets old fast. Define aliases in ~/.ssh/config and connect with a single word like ssh ai-server.

# ~/.ssh/config

# AI server
Host ai-server
    HostName 10.x.10.11
    User admin
    Port 22
    IdentityFile ~/.ssh/id_ed25519

# Backup server
Host backup
    HostName 10.x.10.20
    User root
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

# Reverse proxy
Host proxy
    HostName 10.x.10.5
    User admin
    Port 22
    IdentityFile ~/.ssh/id_ed25519

# Internal server reachable only via jump host
Host internal-db
    HostName 10.x.10.50
    User dbadmin
    ProxyJump proxy

# Global defaults (applied to all hosts)
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    AddKeysToAgent yes
# Usage examples
ssh ai-server          # Connects to 10.x.10.11 as admin
ssh backup             # Connects to 10.x.10.20 as root on port 2222
ssh internal-db        # Tunnels through proxy to reach the DB server

# Works with scp and rsync too
scp file.txt ai-server:/home/admin/
rsync -avz ./data/ backup:/backup/data/

ProxyJump for Internal Servers

Use ProxyJump to reach servers that aren’t directly accessible from outside. Combined with VPN, a single ssh command can reach deeply nested servers across complex network topologies.

5Centralized Key Management

When your team grows and servers multiply, key management needs structure.

One Key Per Person

Each team member generates their own key pair. Collect public keys and register them on servers. When someone leaves, delete their public key to revoke access instantly.

Centralized authorized_keys

Track each server's authorized_keys in Git or deploy via Ansible. This gives you a single-pane view of who has access to what.

Batch Command Execution

With SSH config and key auth in place, run commands across servers simultaneously using for loops or parallel-ssh.

# Run commands across multiple servers
for host in ai-server backup proxy; do
  echo "=== $host ==="
  ssh $host "uptime && df -h / && free -h"
  echo ""
done

# Parallel execution with parallel-ssh (faster)
# sudo apt install pssh
parallel-ssh -H "ai-server backup proxy" -i "uptime"

# Update packages on all servers
for host in ai-server backup proxy; do
  ssh $host "sudo apt update && sudo apt upgrade -y" &
done
wait

6Security Hardening Checklist

SettingConfigEffect
Block root loginPermitRootLogin noForces sudo; no direct root SSH
Change SSH portPort 2222 (example)Avoids default-port scanners
Restrict source IPsAllowUsers admin@10.x.*Only specific subnets can connect
Install fail2banBan after 5 failures for 10 minBlocks brute-force attempts
Block empty passwordsPermitEmptyPasswords noPrevents passwordless account access

fail2ban Configuration

# Install
sudo apt install fail2ban

# SSH-specific config
sudo nano /etc/fail2ban/jail.local

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
bantime = 600
findtime = 600

# Start the service
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# Check ban status
sudo fail2ban-client status sshd

Key Auth + fail2ban Is the Best Combo

Even with password auth disabled, connection attempts still reach the SSH port. fail2ban auto-bans repeated offenders, reducing log noise and server load. For monitoring multiple servers in a single dashboard, see Grafana unified monitoring.

Summary

SSH Key Auth Management Checklist

  • Generate an Ed25519 key — shorter and stronger than RSA
  • Deploy the public key to each server with ssh-copy-id
  • Confirm key login, THEN disable password auth (order matters!)
  • Set up ~/.ssh/config with aliases, ports, and usernames
  • Use ProxyJump for hop-through access to internal servers
  • Block direct root login and change the default SSH port
  • Install fail2ban to auto-ban repeated connection attempts
  • Revoke access instantly by removing a departing team member's public key

SSH key authentication is the most fundamental security practice for server management, and it also makes your daily workflow significantly more convenient. It’s worth setting up with as few as two servers, and it’s essential with five or more. Key generation, deployment, password lockdown, and config aliases — do it all in one pass.

IP addresses, usernames, and hostnames in this article are examples. Adapt them to your actual environment. When changing SSH configuration, always test from a new session while keeping the current one open. Non-commercial sharing is welcome. For commercial use, please contact us.

Need a Server Security Audit?

Treeru provides SSH hardening, firewall configuration, and server infrastructure reviews. From key auth migration to full security hardening — handled end to end.

Get a Security Consultation