Passwordless Authentication

Passwordless Authentication

SSH key-based authentication is more secure than passwords because: keys are cryptographically much longer than any practical password, private keys never travel over the network, and with a passphrase-protected key you get two-factor authentication (something you have + something you know). For automated systems (scripts, Ansible, CI/CD), keys are the only practical option since passwords cannot be automated safely.

Why keys are more secure than passwords

Password authentication:
  Client sends password → Server verifies
  Attack surface: password guessing, phishing, password reuse, MITM

Key authentication:
  Server generates random challenge
  Client signs challenge with private key
  Server verifies signature with stored public key
  Attack surface: compromise of private key file (much harder to exfiltrate)

Generating an SSH key pair

# Generate ED25519 key (modern, fast, secure — recommended)
ssh-keygen -t ed25519 -C "irfan@company.com"

# Generate RSA key (for compatibility with older systems)
ssh-keygen -t rsa -b 4096 -C "irfan@company.com"

Key generation prompt

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/irfan/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase): [type a passphrase]
Enter same passphrase again:
Your identification has been saved in /home/irfan/.ssh/id_ed25519
Your public key has been saved in /home/irfan/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:abc123xyz456.../irfan@company.com
The key's randomart image is: ...

💡 TIP: Always set a passphrase on your personal SSH keys. The passphrase protects the private key if your laptop is stolen or the key file is leaked. For automated systems (Ansible, CI/CD), use passphrase-free keys stored in a secrets manager, not in plaintext files on developer workstations.

Deploying the public key

# Method 1: ssh-copy-id (easiest — requires password auth to be working)
ssh-copy-id user@192.168.1.10

# Specify a non-default key:
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@192.168.1.10

# Method 2: Manual deployment (when password auth is not available)
# Copy the content of your public key:
cat ~/.ssh/id_ed25519.pub
# Example output: ssh-ed25519 AAAA... irfan@company.com

# On the server, append it to authorized_keys:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA... irfan@company.com" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Testing and debugging

# Test key-based login
ssh user@192.168.1.10    # Should not ask for password (or asks for key passphrase)

# If it asks for password instead of key, debug with -vvv
ssh -vvv user@192.168.1.10 2>&1 | head -50

Debug output showing auth methods tried

debug1: Offering public key: /home/irfan/.ssh/id_ed25519 ED25519
debug1: Server accepts key: /home/irfan/.ssh/id_ed25519 ED25519
debug1: Authentication succeeded (publickey).
# OR
debug1: Offering public key: ...
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/irfan/.ssh/id_ed25519
debug1: No more authentication methods to try.
# → Server is not accepting the key — check authorized_keys permissions

# Common causes of key auth failure:
# 1. Wrong permissions on ~/.ssh or authorized_keys on the SERVER
ssh user@server 'ls -la ~/.ssh/'
# Fix: chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys

# 2. Key not in authorized_keys
ssh user@server 'cat ~/.ssh/authorized_keys'

# 3. sshd_config has PubkeyAuthentication no
sudo grep PubkeyAuthentication /etc/ssh/sshd_config

Conclusion

Generate an ED25519 key pair with ssh-keygen -t ed25519, deploy the public key with ssh-copy-id, and test before disabling password auth. When key auth fails, ssh -vvv shows exactly which keys were offered and whether the server accepted them. The most common cause of failure is wrong permissions on ~/.ssh/ (must be 700) or ~/.ssh/authorized_keys (must be 600) on the server — SSH silently ignores keys when permissions are too open.