Secure Shell (SSH)

Establishing an encrypted channel is only half the security equation. A perfectly encrypted connection to an attacker's machine provides no protection—we must verify we're talking to the right server and that the person on the other end is who they claim to be.

SSH's User Authentication Protocol (RFC 4252) solves this challenge through multiple mechanisms, each with distinct security properties, operational characteristics, and use cases. From simple passwords to cryptographic key pairs to hardware security tokens, SSH provides a sophisticated toolkit for identity verification.

The SSH User Authentication Protocol operates after the transport layer establishes encryption. All authentication messages are encrypted, protecting passwords, signatures, and other sensitive data.

Protocol Flow:

Authentication follows a structured negotiation:

SSH_MSG_USERAUTH_REQUEST Structure:

byte      SSH_MSG_USERAUTH_REQUEST (50)
string    user name (UTF-8)
string    service name (typically "ssh-connection")
string    method name ("password", "publickey", etc.)
...       method-specific data

Authentication Methods Defined in Standards:

Password authentication is the simplest method: the client sends the user's password over the encrypted channel, and the server verifies it against its user database.

Protocol Exchange:

byte      SSH_MSG_USERAUTH_REQUEST (50)
string    user name
string    "ssh-connection"
string    "password"
boolean   FALSE (not a password change)
string    password (plaintext over encrypted channel)

Security Properties:

Password Change Support:

SSH supports interactive password changes:

1. Client sends password with change flag = TRUE
2. Client includes old password and new password
3. Server validates old password and applies change
4. Server may respond with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ to force change

This enables password expiration policies through SSH.

Hardening Password Authentication:

If passwords must be used, additional protections help:

# In /etc/ssh/sshd_config:

# Limit authentication attempts per connection
MaxAuthTries 3

# Reduce login timeout
LoginGraceTime 30

# Use PAM for password policies
UsePAM yes

# Consider fail2ban for brute-force protection
# External: fail2ban monitors auth.log and bans IPs

Public key authentication uses cryptographic key pairs to prove identity. The client demonstrates possession of a private key without revealing it, providing strong authentication that cannot be brute-forced.

The Fundamental Principle:

Public key cryptography enables:

1. A private key that must remain secret
2. A public key that can be freely distributed
3. A one-way mathematical relationship: knowing the public key doesn't reveal the private key
4. Operations only the private key owner can perform (signing)
5. Operations anyone with the public key can perform (verification)

Authentication Protocol:

The Signature Proves Identity:

The signature covers:

string    session identifier (from key exchange)
string    SSH_MSG_USERAUTH_REQUEST constant
string    user name
string    service name
string    "publickey"
boolean   TRUE
string    public key algorithm
string    public key blob

The session identifier binding is critical—it proves the signature was generated specifically for this session, preventing replay attacks.

Key Types for Authentication:

Key File Locations:

# Private keys (user):
~/.ssh/id_ed25519
~/.ssh/id_ecdsa
~/.ssh/id_rsa

# Public keys (user):
~/.ssh/id_ed25519.pub
~/.ssh/id_ecdsa.pub
~/.ssh/id_rsa.pub

# Authorized keys (server):
~/.ssh/authorized_keys  # One public key per line

authorized_keys Format:

# Format: [options] key-type base64-encoded-key comment
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGyz... user@laptop
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbm... user@desktop

# With options:
command="/bin/backup",no-port-forwarding ssh-ed25519 AAAAC... backup-agent
from="192.168.1.*" ssh-ed25519 AAAAC... internal-user

The SSH agent solves the usability problem of passphrase-protected keys. Rather than typing passphrases for every connection, the agent holds decrypted private keys in memory, signing authentication challenges on request.

How SSH Agent Works:

Agent Operations:

# Start the agent (usually automatic in desktop environments)
eval $(ssh-agent)

# Add key to agent (prompts for passphrase)
ssh-add ~/.ssh/id_ed25519

# Add with lifetime limit (key removed after timeout)
ssh-add -t 3600 ~/.ssh/id_ed25519  # 1 hour

# List keys in agent
ssh-add -l

# Remove specific key
ssh-add -d ~/.ssh/id_ed25519

# Remove all keys
ssh-add -D

# Lock agent (require passphrase to unlock)
ssh-add -x

Agent Forwarding:

SSH can forward agent connections through SSH sessions, enabling multi-hop authentication without copying private keys:

# Connect with agent forwarding
ssh -A user@jumphost

# From jumphost, authenticate to internal server using local key
ssh user@internal

The internal server's authentication request travels back through the SSH connection to the local agent.

Safer Multi-Hop Connections:

# Using ProxyJump (recommended): agent stays local
ssh -J jumphost user@internal

# Equivalent config in ~/.ssh/config:
Host internal
    User user
    ProxyJump jumphost

# Now simply:
ssh internal

ProxyJump establishes a tunnel through jumphost directly to internal server. Authentication to internal happens through this tunnel, with your agent accessed locally—never exposed to jumphost.

SSH certificates solve the scalability problem of authorized_keys management. Instead of distributing individual public keys to every server, a Certificate Authority (CA) signs user keys, and servers trust keys signed by that CA.

The authorized_keys Scaling Challenge:

With traditional public key authentication:

• Each user's public key must exist in authorized_keys on every server they access
• Adding users means updating hundreds of servers
• Revoking access means updating hundreds of servers
• Key rotation becomes a massive operational burden

SSH Certificates Solve This:

Certificate Contents:

SSH certificates contain:

• The user's public key
• The signing CA's identity
• A validity period (not before, not after)
• A serial number for revocation tracking
• Principals: authorized usernames
• Extensions: permitted capabilities
• Critical options: restrictions

Creating and Using Certificates:

# Generate CA key pair (do this once, protect the private key!)
ssh-keygen -t ed25519 -f /etc/ssh/ca_user_key -C "SSH User CA"

# Sign a user's public key to create certificate
ssh-keygen -s /etc/ssh/ca_user_key \
    -I "alice@example.com" \
    -n alice,admin \
    -V +52w \
    ~/.ssh/id_ed25519.pub

# Output: ~/.ssh/id_ed25519-cert.pub

# Examine certificate
ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub

Server Configuration:

# In /etc/ssh/sshd_config:

# Trust keys signed by this CA
TrustedUserCAKeys /etc/ssh/ca_user_key.pub

# Optional: restrict authentication to specific principals
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

Keyboard-interactive authentication (RFC 4256) provides flexible challenge-response dialog. Unlike simple password authentication, it supports multiple prompts, variable challenges, and integration with external authentication systems.

Protocol Exchange:

Use Cases:

One-Time Passwords (OTP):

• First prompt: "Password:" → user's regular password
• Second prompt: "Verification code:" → TOTP from authenticator app

RADIUS Integration:

• Challenge from RADIUS server relayed to SSH client
• Response forwarded back to RADIUS for verification

Hardware Token Authentication:

• Server requests challenge-response from hardware token
• Client relays challenge to user; user provides token response

Adaptive Authentication:

• Different challenges based on source IP, time, or user history
• Risk-based additional verification steps

PAM Integration (Pluggable Authentication Modules):

On Linux/Unix, keyboard-interactive typically uses PAM:

# /etc/ssh/sshd_config:
ChallengeResponseAuthentication yes
UsePAM yes

# /etc/pam.d/sshd:
auth required pam_google_authenticator.so
auth required pam_unix.so

This configuration requires both password (pam_unix) and TOTP (pam_google_authenticator).

TOTP Configuration Example:

# User generates TOTP secret:
google-authenticator

# Creates ~/.google_authenticator with secret and config
# User scans QR code with authenticator app

# Subsequent SSH logins prompt for:
# 1. Password
# 2. Verification code from app

Modern SSH supports FIDO2 (WebAuthn) hardware security keys like YubiKey. These devices store private keys in tamper-resistant hardware, requiring physical user presence to authorize signatures. This provides phishing-resistant authentication that software cannot fully replicate.

FIDO2 SSH Key Types:

How FIDO2 Keys Work:

1. Key Generation: Private key generated and stored on the hardware device
2. Public Key Export: Only the public key is extractable for server configuration
3. Authentication: Server sends challenge; SSH client requests signature from device
4. User Presence: Device requires physical touch/PIN before signing
5. Response: Signed challenge returned to server for verification

The private key never leaves the hardware device—not even encrypted.

Resident vs Non-Resident Keys:

# Non-resident: key handle stored locally, device holds private key
ssh-keygen -t ed25519-sk
# Output: id_ed25519_sk, id_ed25519_sk.pub
# The .sk file contains a key handle, not the private key

# Resident: key fully stored on device, discoverable
ssh-keygen -t ed25519-sk -O resident
# Key can be retrieved from device without local files:
ssh-keygen -K  # Download resident keys from device

Configuration and Usage:

# Generate FIDO2 key (prompts for device touch)
ssh-keygen -t ed25519-sk -O application=ssh:production-servers

# Require PIN verification (not just touch)
ssh-keygen -t ed25519-sk -O verify-required

# Deploy public key normally
cat ~/.ssh/id_ed25519_sk.pub >> authorized_keys

# SSH usage (device touch required for each connection)
ssh user@server  # LED blinks, touch to authorize

SSH supports requiring multiple authentication methods—a user must succeed at several methods before access is granted. This multi-factor authentication significantly increases security.

Authentication Progression:

When multiple methods are required, SSH_MSG_USERAUTH_FAILURE includes:

• authentications that can continue: remaining required methods
• partial success: TRUE if current method succeeded

The client must then attempt remaining methods.

Server Configuration:

# /etc/ssh/sshd_config:

# Require both publickey AND keyboard-interactive:
AuthenticationMethods publickey,keyboard-interactive

# Require publickey alone, OR both password and keyboard-interactive:
AuthenticationMethods publickey password,keyboard-interactive

# Per-user configuration:
Match User admin
    AuthenticationMethods publickey,keyboard-interactive

Match User regular
    AuthenticationMethods publickey

Factor Categories:

• Something you know: Passwords, PINs, passphrases
• Something you have: SSH private key, hardware token, phone with authenticator app
• Something you are: Biometrics (fingerprint, face recognition on devices)

True MFA requires factors from different categories. Two passwords is not MFA—it's just double password authentication.

Recommended MFA Approaches:

We've explored the full spectrum of SSH authentication—from basic passwords to cryptographic key pairs to hardware security tokens. Let's consolidate the essential knowledge:

What's next:

With authentication mastered, we'll explore SSH's powerful tunneling capabilities. The next page covers local port forwarding, remote port forwarding, dynamic SOCKS proxies, and VPN-style tunnel configurations—enabling SSH to secure any TCP-based communication.