🔒 security

SSH Key-Based Authentication for Secure Server Access

Implement passwordless SSH authentication using key pairs. This guide covers key generation, server configuration, and security best practices for production environments.

Published:
Author: ServerHi Editorial Team
SSH keys and terminal showing secure authentication process

Introduction

Secure Shell (SSH) remains the standard for remote server administration, providing encrypted communication between your workstation and servers. While password-based authentication works, it exposes your servers to brute force attacks, credential stuffing, and password leakage. SSH key-based authentication eliminates these vulnerabilities by replacing passwords with cryptographic key pairs that are essentially impossible to crack through guessing.

Key-based authentication offers several security advantages over passwords. SSH keys can be 2048 bits or longer, providing billions of possible combinations compared to the limited complexity of typical user passwords. Keys never transmit over the network, eliminating interception risks. Additionally, key-based authentication integrates with automated scripts and deployment pipelines, enabling secure, passwordless operations at scale.

This comprehensive guide walks you through implementing SSH key authentication from key generation to production-hardened server configuration. You will learn how to create secure key pairs, configure servers to accept key-based authentication only, manage multiple keys for different purposes, and implement additional security measures that protect your infrastructure from unauthorized access.

Understanding SSH Keys

Before implementation, learn how SSH keys work. This knowledge helps you make informed decisions about configuration and security.

SSH keys come in pairs: a private key that you keep secret and a public key that you share with servers. The mathematics behind these keys ensure that something encrypted with the public key can only be decrypted by the corresponding private key. When you connect to a server, your SSH client proves possession of the private key without ever transmitting it across the network.

The most common key type is RSA, which scales well from 2048 to 4096 bits. Ed25519 offers modern elliptic curve cryptography with smaller keys and faster operations, making it excellent for most use cases. ECDSA, another elliptic curve algorithm, is supported widely but has some complexity around NIST curves that makes Ed25519 preferable for new deployments.

Generating SSH Key Pairs

The first step involves creating a new key pair with appropriate settings for your security requirements.

Creating Ed25519 Keys

Ed25519 keys provide excellent security with fast generation and authentication. This key type represents the modern standard for SSH authentication:

# Generate Ed25519 key pair
ssh-keygen -t ed25519 -C "your-email@example.com"

# Saving the keypair
Enter file in which to save the key (/Users/username/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

# View the public key
cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5BBBB... your-email@example.com

The passphrase adds an additional layer of protection. Even if someone obtains your private key file, they cannot use it without the passphrase. For automated systems, you may omit the passphrase, but consider the security implications carefully.

Creating RSA Keys

Some older systems do not support Ed25519 keys. RSA remains universally compatible and is the fallback choice when Ed25519 is not available:

# Generate RSA key with 4096 bits
ssh-keygen -t rsa -b 4096 -C "your-email@example.com"

# Specify a custom file location
ssh-keygen -t ed25519 -f ~/.ssh/production-key -C "production-servers"

Managing Multiple Keys

Production environments often require separate keys for different access levels or systems:

# Generate separate keys for different environments
ssh-keygen -t ed25519 -f ~/.ssh/personal -C "personal-devices"
ssh-keygen -t ed25519 -f ~/.ssh/work -C "work-laptop"
ssh-keygen -t ed25519 -f ~/.ssh/automation -C "ci-pipeline"

# Configure which key to use for which host
# ~/.ssh/config
Host production
    HostName prod-server.example.com
    User admin
    IdentityFile ~/.ssh/work
    IdentitiesOnly yes

Host staging
    HostName staging.example.com
    User deploy
    IdentityFile ~/.ssh/work
    IdentitiesOnly yes

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/automation
    IdentitiesOnly yes

Configuring SSH Servers

With keys generated, configure your servers to accept key-based authentication.

Adding Public Keys to Servers

The public key must be added to the server’s authorized_keys file:

# Copy public key to server (using ssh-copy-id)
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server.example.com

# Manual method if ssh-copy-id is unavailable
ssh user@server.example.com
mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

# Add public key content (from id_ed25519.pub)
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5BBBB... your-email@example.com" >> ~/.ssh/authorized_keys

# Copy file to server using SCP if you cannot SSH yet
scp ~/.ssh/id_ed25519.pub user@server.example.com:/tmp/
ssh user@server.example.com "cat /tmp/id_ed25519.pub >> ~/.ssh/authorized_keys && rm /tmp/id_ed25519.pub"

Hardening SSH Server Configuration

Edit the SSH server configuration to enforce key-based authentication and disable less secure options:

# Edit SSH daemon configuration
sudo nano /etc/ssh/sshd_config

# Recommended secure settings
Port 2222                                  # Change default port
PermitRootLogin no                         # Disable root login
PubkeyAuthentication yes                   # Enable key auth
PasswordAuthentication no                  # Disable password auth
ChallengeResponseAuthentication no         # Disable challenge-response
MaxAuthTries 3                             # Limit authentication attempts
ClientAliveInterval 300                    # Disconnect idle clients
ClientAliveCountMax 2                      # Number of keepalives before disconnect
X11Forwarding no                           # Disable X11 unless needed
AllowUsers admin deploy                    # Limit allowed users
LoginGraceTime 60                          # Time to complete login

# Disable empty passwords
PermitEmptyPasswords no

# Use strong algorithms
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com
KexAlgorithms curve25519-sha256

# Log successful and failed attempts
SyslogFacility AUTH
LogLevel INFO

Validate the configuration before restarting:

# Test configuration syntax
sudo sshd -t

# If no errors, restart the service
sudo systemctl restart sshd

# Verify the service is running
sudo systemctl status sshd

Configuring Sudo Access

For users who need administrative privileges, configure passwordless sudo for key-based users:

# Create sudoers file for specific user
sudo visudo -f /etc/sudoers.d/admin-users

# Add configuration
%admin ALL=(ALL) NOPASSWD: ALL

# Or for specific user
deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /usr/bin/docker

Connecting with SSH Keys

With server configuration complete, connect using your key-based authentication.

Basic Connection

# Connect with default key
ssh user@server.example.com

# Specify a particular key
ssh -i ~/.ssh/production-key user@server.example.com

# Connect with verbose output for debugging
ssh -vvv user@server.example.com

SSH Agent Management

The SSH agent holds your private keys in memory, eliminating repeated passphrase entry:

# Start SSH agent
eval "$(ssh-agent -s)"

# Add your key to the agent
ssh-add ~/.ssh/id_ed25519

# List loaded keys
ssh-add -l

# Remove all keys from agent
ssh-add -D

Multiplexing Connections

SSH connection multiplexing reuses connections for multiple sessions, significantly reducing connection latency:

# Configure in ~/.ssh/config
Host *
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 600

# Create socket directory
mkdir -p ~/.ssh/sockets
chmod 700 ~/.ssh/sockets

Advanced Security Measures

Beyond basic key authentication, implement additional measures for production environments.

Fail2Ban Installation

Fail2Ban monitors authentication logs and blocks IP addresses exhibiting attack patterns:

# Install Fail2Ban
sudo apt install fail2ban

# Create local configuration
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

# Configure SSH protection
sudo nano /etc/fail2ban/jail.local

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

# Start and enable Fail2Ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# Check Fail2Ban status
sudo fail2ban-client status

Two-Factor Authentication

Add an additional authentication factor for sensitive servers:

# Install Google Authenticator PAM module
sudo apt install libpam-google-authenticator

# Run setup for each user
google-authenticator

# Configure SSH to use PAM
sudo nano /etc/pam.d/sshd

# Add this line before @include common-auth
auth required pam_google_authenticator.so

# Update sshd_config
sudo nano /etc/ssh/sshd_config

ChallengeResponseAuthentication yes
AuthenticationMethods password,keyboard-interactive

Key Expiration and Rotation

Implement key rotation policies to limit exposure from compromised keys:

# Create a new key for rotation
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519-new -C "rotation-$(date +%Y%m%d)"

# Add new key to authorized_keys
cat ~/.ssh/id_ed25519-new.pub >> ~/.ssh/authorized_keys

# Test new key before removing old
ssh -i ~/.ssh/id_ed25519-new user@server.example.com

# Remove old key from authorized_keys
# Edit authorized_keys and remove the old line

# Distribute new key to other servers
ssh-copy-id -i ~/.ssh/id_ed25519-new user@other-server.example.com

Troubleshooting Common Issues

Key-based authentication problems usually stem from a few common causes.

Permission Problems

SSH refuses keys with incorrect permissions:

# Correct permissions for home directory
chmod 700 ~/.ssh

# Correct permissions for private key
chmod 600 ~/.ssh/id_ed25519

# Correct permissions for public key
chmod 644 ~/.ssh/id_ed25519.pub

# Correct permissions for authorized_keys
chmod 600 ~/.ssh/authorized_keys

Key Not Accepted

When servers reject your key, verify the authorized_keys file:

# Check server-side authorized_keys
ssh user@server.example.com "cat ~/.ssh/authorized_keys"

# Verify key matches
ssh-keygen -lf ~/.ssh/id_ed25519.pub

# Check SSH daemon logs
ssh user@server.example.com "sudo tail -50 /var/log/auth.log"

Connection Refused

Connection refused errors indicate networking or service issues:

# Verify SSH is running
ssh user@server.example.com "sudo systemctl status sshd"

# Check firewall rules
ssh user@server.example.com "sudo ufw status"

# Verify port is listening
ssh user@server.example.com "sudo ss -tlnp | grep ssh"

Automation and Scripts

Key-based authentication enables secure automation for deployment and management scripts.

Passwordless Script Execution

Configure scripts to use keys for remote operations:

# Script template for remote operations
#!/bin/bash
KEY_FILE="${HOME}/.ssh/automation"
SERVER="deploy@staging.example.com"

# Verify key exists
if [ ! -f "$KEY_FILE" ]; then
    echo "Error: SSH key not found at $KEY_FILE"
    exit 1
fi

# Run remote commands
ssh -i "$KEY_FILE" -o StrictHostKeyChecking=no -o BatchMode=yes "$SERVER" << 'EOF'
    cd /opt/myapp
    git pull origin main
    docker-compose up -d --build
    exit 0
EOF

if [ $? -eq 0 ]; then
    echo "Deployment successful"
else
    echo "Deployment failed"
    exit 1
fi

CI/CD Pipeline Integration

Configure CI/CD systems to use deploy keys for repository access:

# Generate deploy key (no passphrase)
ssh-keygen -t ed25519 -f ~/.ssh/deploy-key -N "" -C "ci-pipeline"

# Add as deploy key in GitHub/GitLab
# Repository → Settings → Deploy Keys

# Configure git to use deploy key
GIT_SSH_COMMAND="ssh -i /path/to/deploy-key -o StrictHostKeyChecking=no"
export GIT_SSH_COMMAND

# Clone using deploy key
git clone git@github.com:organization/repo.git

Conclusion

SSH key-based authentication provides secure, manageable access to your servers. Start with key generation and basic server configuration, then add Fail2Ban protection, two-factor authentication for sensitive systems, and key rotation procedures for long-term security.

The initial setup investment pays dividends through reduced attack surface, simplified credential management, and automated deployment capabilities. Regularly audit your SSH configurations and key access to maintain security hygiene across your infrastructure.

Related Guides:

Tags

#SSH #authentication #keys #Linux #security #server

Related Tutorials