SSH Key Management¶

Scope and operational contract¶

This guide targets OpenSSH clients and servers. Exact algorithms, service names, configuration paths, and certificate support depend on the operating system, OpenSSH release, cryptographic policy, and FIPS requirements.

Evidence status: Commands are illustrative and were not executed by this document. Record the installed versions and effective sshd configuration before relying on them.
Key custody: Never transmit or paste a private key. Prefer a passphrase, a constrained agent or hardware-backed key, protected backups, and verified host keys.
Change sequence: Inventory key owners and destinations, add a new key, test it in a second session, revoke the old key, then validate logs. Do not disable password access until a tested key or MFA path and a break-glass route exist.
Failure handling: Keep an existing administrator session open. Validate sshd syntax before reload; if a new connection fails, restore the previous configuration instead of repeatedly changing permissions.
Completion evidence: Capture fingerprints, accountable owners, expiry or review dates, successful and denied login tests, effective authorization restrictions, and revocation results.

Public-key authentication reduces password guessing exposure, but it is not automatically safer: stolen unencrypted keys, over-broad authorized_keys entries, unverified host keys, and unmanaged copies remain material risks. Ed25519 is a strong default where the platform policy supports it; use an approved compatible algorithm otherwise.

Complete guide to SSH key-based authentication setup

Overview¶

SSH key authentication can reduce password-guessing exposure and support automation, but only when private keys, host verification, authorization scope, rotation, and revocation are managed.

flowchart LR
    A[Client] -->|Private Key| B{SSH Server}
    B -->|Verify| C[authorized_keys]
    C -->|Public Key Match| D[Access Granted]

Key Generation¶

Generate SSH Key Pair¶

# Generate RSA only when compatibility or policy requires it
ssh-keygen -t rsa -b 4096 -C "[email protected]"

# Generate Ed25519 key (recommended)
ssh-keygen -t ed25519 -C "[email protected]"

# With custom filename
ssh-keygen -t ed25519 -f ~/.ssh/myserver_key -C "myserver-access"

Key files created: - ~/.ssh/id_ed25519 - Private key (keep secret!) - ~/.ssh/id_ed25519.pub - Public key (share with servers)

Server Setup¶

1. Copy Public Key to Server¶

# Method 1: ssh-copy-id (easiest)
ssh-copy-id user@server-ip

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

# Method 3: Direct paste
# Copy content of ~/.ssh/id_ed25519.pub
# Paste into server's ~/.ssh/authorized_keys

2. Set Correct Permissions¶

# On the server
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

3. Disable Password Authentication¶

Edit /etc/ssh/sshd_config:

# Disable password auth
PasswordAuthentication no
PubkeyAuthentication yes

# Optional: More security
PermitRootLogin prohibit-password
PermitEmptyPasswords no

Validate the configuration, keep the current session open, and reload before testing a second session:

sudo sshd -t && sudo systemctl reload sshd

Multiple Users Setup¶

Each user needs their own authorized_keys:

# For user 'john'
/home/john/.ssh/authorized_keys

# For user 'jane'
/home/jane/.ssh/authorized_keys

Permissions¶

# Set ownership
sudo chown -R john:john /home/john/.ssh
sudo chown -R jane:jane /home/jane/.ssh

# Set permissions
sudo chmod 700 /home/john/.ssh
sudo chmod 600 /home/john/.ssh/authorized_keys

Using Keys¶

SSH Connection¶

# Default key
ssh user@server

# Specific key
ssh -i ~/.ssh/myserver_key user@server

# With custom port
ssh -i ~/.ssh/myserver_key -p 2222 user@server

SCP with Key¶

# Copy file to server
scp -i ~/.ssh/myserver_key file.txt user@server:/path/

# Copy with custom port
scp -P 2222 -i ~/.ssh/myserver_key file.txt user@server:/path/

SSH Config File¶

Create ~/.ssh/config:

Host myserver
    HostName 192.168.1.100
    User john
    Port 22
    IdentityFile ~/.ssh/myserver_key

Host production
    HostName prod.example.com
    User deploy
    Port 2222
    IdentityFile ~/.ssh/production_key

Then connect with:

ssh myserver
ssh production

PuTTY Key Conversion¶

Generate Key with PuTTYgen¶

Open PuTTYgen
Click "Generate" and move mouse for randomness
Save public key
Save private key (.ppk format)

Convert PuTTY Key to OpenSSH¶

# Using PuTTYgen GUI:
# 1. Load private key (.ppk)
# 2. Conversions → Export OpenSSH key
# 3. Save as ~/.ssh/id_rsa (or desired name)

# Or using command line (Linux):
puttygen mykey.ppk -O private-openssh -o ~/.ssh/mykey

Convert OpenSSH to PuTTY¶

# Using PuTTYgen GUI:
# 1. Conversions → Import key
# 2. Select OpenSSH private key
# 3. Save private key (.ppk)

SSH Agent¶

Start Agent¶

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

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

# List added keys
ssh-add -l

Persistent Agent (bashrc)¶

Add to ~/.bashrc:

if [ -z "$SSH_AUTH_SOCK" ]; then
   eval "$(ssh-agent -s)"
   ssh-add ~/.ssh/id_ed25519
fi

Security Best Practices¶

Practice	Description
Use Ed25519	Modern, secure, fast
Passphrase	Add passphrase to private keys
No root login	Use `PermitRootLogin no`
Limit users	Use `AllowUsers` directive
Audit keys	Regularly review authorized_keys
Rotate keys	Replace keys periodically

Troubleshooting¶

Permission Denied¶

# Check permissions
ls -la ~/.ssh/
# Should be: drwx------ (700)

ls -la ~/.ssh/authorized_keys
# Should be: -rw------- (600)

Debug Connection¶

ssh -vvv user@server

Check Server Logs¶

sudo tail -f /var/log/auth.log
# or
sudo journalctl -u sshd -f