Configure SSH key authentication and disable password login for secure server access

Beginner 20 min Apr 03, 2026 29 views
Ubuntu 24.04 Ubuntu 22.04 Debian 12 AlmaLinux 9 Rocky Linux 9 Fedora 41

Set up SSH public key authentication on Linux servers and disable password-based logins to prevent brute force attacks and improve security. This tutorial covers key generation, server configuration, and troubleshooting common authentication issues.

Prerequisites

  • Root or sudo access to the server
  • SSH client installed on local machine
  • Basic knowledge of command line operations

What this solves

SSH password authentication is vulnerable to brute force attacks and credential theft. Public key authentication provides cryptographic security that's nearly impossible to crack, while disabling password login eliminates the attack vector entirely. This setup is essential for production servers, cloud instances, and any system exposed to the internet.

Step-by-step configuration

Generate SSH key pair on client machine

Create a new SSH key pair on your local machine or workstation. The private key stays on your client, while the public key gets copied to the server.

ssh-keygen -t ed25519 -C "your-email@example.com" -f ~/.ssh/server_key

When prompted, enter a strong passphrase to protect your private key. This creates two files: ~/.ssh/server_key (private) and ~/.ssh/server_key.pub (public).

Copy public key to server

Use ssh-copy-id to automatically copy your public key to the server and set correct permissions. Replace username and server-ip with your actual values.

ssh-copy-id -i ~/.ssh/server_key.pub username@203.0.113.10

Enter your password when prompted. This command copies the key to ~/.ssh/authorized_keys on the server and sets the correct permissions automatically.

Test SSH key authentication

Verify that key-based authentication works before disabling password login. Connect using your private key to ensure everything is configured correctly.

ssh -i ~/.ssh/server_key username@203.0.113.10

You should connect without being prompted for a password (only your key passphrase if you set one). If this fails, do not proceed to disable password authentication.

Backup SSH configuration

Create a backup of the SSH daemon configuration before making changes. This allows you to restore the original settings if needed.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

Configure SSH daemon settings

Edit the SSH daemon configuration to disable password authentication and enforce key-based login. Use your preferred text editor to modify the configuration.

sudo nano /etc/ssh/sshd_config

Find and modify these settings. If a line is commented out (starts with #), uncomment it and set the value:

# Disable password authentication
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Ensure public key authentication is enabled

PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys

Disable empty passwords

PermitEmptyPasswords no

Additional security settings

PermitRootLogin no MaxAuthTries 3 ClientAliveInterval 300 ClientAliveCountMax 2

Validate SSH configuration

Test the SSH configuration syntax before restarting the service. This prevents lockout from configuration errors.

sudo sshd -t

If there are no errors, the command returns silently. Any configuration syntax errors will be displayed and must be fixed before proceeding.

Restart SSH service

Apply the configuration changes by restarting the SSH daemon. The service remains active during restart, so existing connections stay open.

sudo systemctl restart ssh
sudo systemctl status ssh
sudo systemctl restart sshd
sudo systemctl status sshd

Configure SSH client for convenience

Create an SSH client configuration file to automatically use the correct key and settings for your server. This eliminates the need to specify the key file every time.

Host myserver
    HostName 203.0.113.10
    User username
    IdentityFile ~/.ssh/server_key
    IdentitiesOnly yes
    ServerAliveInterval 60

Set secure permissions on the SSH config file:

chmod 600 ~/.ssh/config

Set up additional authorized keys

If multiple users or machines need access, add their public keys to the authorized_keys file. Each public key should be on a separate line.

cat additional_key.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh
Never use chmod 777. SSH keys require specific permissions: 600 for private keys and authorized_keys, 644 for public keys, and 700 for the .ssh directory. Incorrect permissions will cause authentication failures.

Verify your setup

Test your SSH key authentication from a new terminal session to ensure everything works correctly:

# Test connection with key authentication
ssh myserver

Verify SSH service is running

sudo systemctl status ssh # Ubuntu/Debian sudo systemctl status sshd # AlmaLinux/Rocky/Fedora

Check SSH configuration

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication'

Verify authorized keys permissions

ls -la ~/.ssh/ ls -la ~/.ssh/authorized_keys

You should see output similar to:

passwordauthentication no
pubkeyauthentication yes

Common issues

SymptomCauseFix
Permission denied (publickey)Wrong key permissions or locationchmod 600 ~/.ssh/authorized_keys && chmod 700 ~/.ssh
SSH still asks for passwordConfiguration not applied or syntax errorCheck sudo sshd -t and restart SSH service
Could not load host keySSH host keys missing or corruptedsudo ssh-keygen -A to regenerate host keys
Connection closed by serverAllowUsers or DenyUsers restrictionsCheck SSH config for user access restrictions
Key not offered by clientToo many keys in SSH agentUse ssh -o IdentitiesOnly=yes -i keyfile
SELinux blocking SSH keysIncorrect SELinux contextrestorecon -R ~/.ssh to fix context
Note: Always keep a backup method to access your server (like console access through your hosting provider) in case of SSH configuration issues. Consider setting up fail2ban for additional SSH protection after completing this setup.

Next steps

#ssh #authentication #security #public-key #hardening

Need help?

Don't want to manage this yourself?

We handle infrastructure for businesses that depend on uptime. From initial setup to ongoing operations.

Talk to an engineer