How to disable SSH password login securely: Step-by-step
Learn how to disable SSH password login securely by switching to key-based authentication. This guide covers essential config changes, testing, and recovery to protect remote access.
To disable SSH password login, switch to key-based authentication and enforce it on the server. Enable PubkeyAuthentication, set PasswordAuthentication to no, and disable password-based challenges. After saving sshd_config, restart the SSH service and test with an SSH key from a trusted client. Always keep a backup access method in case you lock yourself out.
why disable ssh password login
Security best practices increasingly advocate for key-based authentication as the primary method to access servers via SSH. By eliminating password-based login, you reduce exposure to brute-force attacks, credential stuffing, and password reuse risks across services. The Default Password team emphasizes that organizations and individual admins should treat SSH access like a critical service—protect it with strong keys, proper permissions, and monitored activity. In practice, switching to key-based authentication does not merely block password login; it also changes how you manage access, rotate keys, and audit sessions. This approach aligns with core security principles: least privilege, defense in depth, and least exposure.
According to Default Password, adopting SSH key-based authentication significantly lowers attack surfaces when remote access is needed, especially for automated processes and admins with remote duties.
Tools & Materials
- Administrative access to the server (sudo/root)(Needed to edit sshd_config and restart the SSH service.)
- SSH key pair (public/private)(Generated on the client with ssh-keygen or equivalent; keep private key secure.)
- Text editor (nano, vi, etc.)(Used to edit /etc/ssh/sshd_config safely.)
- Backup of sshd_config(Optional but strongly recommended before changes.)
- Alternate access method (e.g., console access or another user with key-based login)(Ensure you can regain access if key-based login fails.)
Steps
Estimated time: 15-25 minutes
- 1
Back up and verify access
Create a backup of the current sshd_config and confirm you have at least one way to log in if something goes wrong. This preserves a rollback option and prevents accidental lockout.
Tip: Store the backup in a secure location and note the server's current SSH settings. - 2
Confirm an SSH key pair exists
Ensure you have a working SSH key pair on the client machine and that the public key is already present in the server's ~/.ssh/authorized_keys for at least one user you will use to login.
Tip: Test locally with ssh -i /path/to/key user@server before changing server config. - 3
Edit sshd_config to disable passwords
Open /etc/ssh/sshd_config and set PasswordAuthentication no. Also ensure PubkeyAuthentication is set to yes and ChallengeResponseAuthentication to no to disable keyboard-interactive prompts.
Tip: Use a local editor to avoid broken SSH sessions during edits. - 4
Disable password login for root (carefully)
Set PermitRootLogin prohibit-password or no, depending on your OpenSSH version, to prevent password-based root logins while preserving key-based access for root if needed.
Tip: Prefer non-root admin accounts for daily tasks; reserve root access for emergency maintenance. - 5
Apply additional hardening options
Optionally set AuthenticationMethods publickey to require a key for authentication, and consider Disable حق to prevent password-based fallbacks.
Tip: Keep a note of any extra options you enable and verify they don’t block legitimate logins. - 6
Restart SSH service
Reload or restart SSH so changes take effect: systemctl restart sshd (Linux), service sshd restart (older systems).
Tip: If you’re connected via SSH, consider opening a new session to test while keeping the original session alive. - 7
Test login with SSH key
From a trusted client, attempt login using the key. Confirm password login fails and that you can access the server with your key.
Tip: If login fails, revert changes using the backup sshd_config and investigate the error. - 8
Plan for recovery and future maintenance
Document the changes, keep a second admin account with a separate key, and set up monitoring for SSH access to detect anomalies.
Tip: Regularly rotate keys and review authorized_keys for unused entries.
Your Questions Answered
What does disabling SSH password login accomplish?
Disabling password login reduces the risk of brute-force attacks and credential theft by ensuring only SSH keys can be used for authentication. This strengthens remote access security when managed carefully.
Disabling password login makes SSH access rely on keys, which is safer against password-based attacks.
Can I disable passwords for all users, including non-admins?
Yes, you can disable PasswordAuthentication system-wide, but you should ensure every user has a valid SSH key. It’s common to apply this per-user or per-group to avoid unintended lockouts.
You can require keys for all users, but verify every regular user has a working SSH key before applying the change.
What if I only need temporary access during maintenance?
Use a separate maintenance account with a key-based login, or temporarily re-enable PasswordAuthentication with strict controls, then revert after maintenance.
Keep a dedicated maintenance key and method to revert changes quickly if needed.
How can I verify that I’m no longer using password authentication?
Check sshd_config for PasswordAuthentication no and test by attempting a password-based login from a client. If access fails while a key-based login succeeds, the change is effective.
Try logging in with a password to confirm it’s blocked, then verify key-based login works.
Are there risks to disabling SSH password login remotely?
The main risk is being locked out if you misconfigure SSH or lose access to keys. Mitigate by having a backup admin account and console access.
Lockout risk exists; prepare a recovery path before applying the change.
Key Takeaways
- Enable key-based auth and disable PasswordAuthentication.
- Test access with a new SSH session before closing the old one.
- Keep a backup admin account for recovery and audit SSH activity.
