Why Use SSH Public Key Authentication instead of Passwords?
Password-based SSH access is easily targeted by brute-force and credential-stuffing attacks. Public key authentication is significantly more secure because there’s no password to guess — only a private key you hold.
Step 1: Prepare Your Remote Server
Log into your remote server and create a .ssh directory in your user’s home directory, if it doesn’t exist yet:
cd ~ mkdir -p ~/.ssh chmod 700 ~/.ssh
Step 2: Generate an SSH Key-Pair on the Client
On your local (client) machine, generate a key-pair:
ssh-keygen -t rsa -b 4096 -C "YourCommentHere"
- You can press Enter to accept the default file name.
- When prompted for a passphrase, you may leave it empty (though using a passphrase is more secure).
- You’ll end up with
~/.ssh/id_rsa(private key — do not share) and~/.ssh/id_rsa.pub(public key).

Step 3: Install Your Public Key on the Remote Server
Use ssh-copy-id to upload your public key:
$ ssh-copy-id -i ~/.ssh/id_rsa.pub username@remote-server
You’ll be prompted for the remote user’s password this one time.
Once done, you should be able to log in without a password:
ssh username@remote-server
(Optional) If ssh-copy-id is unavailable, you can manually append the public key:
cat ~/.ssh/id_rsa.pub | ssh username@remote-server 'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'
Step 4: Disable SSH Password Authentication
Once key-based login works reliably, you can harden your SSH server configuration.
On the remote server, edit /etc/ssh/sshd_config:
sudo vi /etc/ssh/sshd_config
Locate and change (or add) these lines:
PermitRootLogin no PasswordAuthentication no ChallengeResponseAuthentication no UsePAM no
Note: Disabling UsePAM may interfere with other authentication methods — test carefully.
Save the file, then restart SSH:
Save and restart SSH server:
sudo systemctl restart sshd # or: sudo /etc/init.d/ssh restart
To test whether password login is truly disabled:
ssh -o PubkeyAuthentication=no username@remote-server
You should see something like:
Permission denied (publickey).
Final Thoughts
- Use a strong key-pair (e.g., 4096-bit RSA or Ed25519).
- Keep your private key safe — never share it.
- Consider adding a passphrase to your private key for extra security.
- When this is in place, your server becomes far less vulnerable to brute-force or credential-harvest attacks.
- Keep backups of your keys and authorized_keys file — you don’t want to lock yourself out.
