PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchTo disable SSH password login without locking yourself out, first prove that key-based access works in a second terminal. Then set PasswordAuthentication no and KbdInteractiveAuthentication no, validate the daemon configuration, reload the correct service, and test both failure and success cases.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
What disabling SSH password login actually changes
OpenSSH has more than one way to ask for a password. The PasswordAuthentication directive controls the ordinary password method and defaults to yes in the OpenSSH manual, so an otherwise unmodified daemon can accept account passwords. KbdInteractiveAuthentication controls keyboard-interactive authentication, a mechanism commonly connected to PAM and capable of presenting a password prompt. The OpenBSD sshd_config(5) manual says this option accepts only yes or no and documents a default of yes.
As an Amazon Associate I earn from qualifying purchases.
For key-only access, disable both methods while explicitly leaving public-key authentication enabled:
PasswordAuthentication noblocks the normal SSH password method.KbdInteractiveAuthentication noblocks keyboard-interactive prompts, including PAM-backed password prompts that could otherwise remain available.PubkeyAuthentication yeskeeps SSH keys enabled. It is normally enabled, but stating it explicitly makes the intended policy clear.
This change affects SSH authentication, not passwords used by sudo after you have logged in, local console logins, database credentials, or application accounts. Those systems have separate policies.
Before changing anything: prevent a lockout
The main operational risk is losing your only working login. Keep the current SSH session open until a new session has authenticated with a key after the reload. Do not test by closing your last shell first.
- Open a second terminal. Leave the original session connected. You need two independent sessions so a mistake in the new configuration does not remove your recovery path.
- Prove key authentication works now. Connect with the exact account and key you intend to keep using, for example
ssh -i ~/.ssh/id_ed25519 user@server. Confirm that the session reaches a shell without asking for the account password. - Identify the account and key. Record the Linux username, hostname or IP address, SSH port if it is not 22, and the private-key path. A key that works for one account does not automatically work for another.
- Confirm administrative access. The configuration file and service reload require root privileges, normally through
sudo. Check that your account can runsudo -vbefore making the edit. - Keep an out-of-band route available. If your VPS provider offers a serial console, web console, rescue environment, or recovery boot, know how to open it. This is a fallback if SSH configuration or networking fails.
- Record the current configuration. Save a copy before editing. The main file is commonly
/etc/ssh/sshd_config, and additional snippets may be under/etc/ssh/sshd_config.d/.
Do not rely on an existing session as proof that a new connection will work: an already-authenticated session can remain open even after a configuration change that rejects every new login.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Inspect the settings that are already present
Search the main file and all drop-ins for authentication directives:
sudo grep -rni 'passwordauthentication' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/Also inspect the related methods and root policy:
sudo grep -rniE 'kbdinteractiveauthentication|pubkeyauthentication|permitrootlogin|usepam' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/A line beginning with # is a comment and does not set a value. Multiple active lines can be confusing, particularly when a distribution or hosting image ships its own snippets. The daemon’s effective configuration is more useful than a single file, so after making the change use sshd -T to see what the running configuration would use.
On systems where the daemon binary is not in the ordinary user path, run the command as root:
sudo sshd -T | grep -iE 'passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|permitrootlogin'Do not treat a commented default as an active setting. Conversely, do not assume that an option is unset simply because it is absent from the main file; an included drop-in may define it.
Recommended Free Tools
Choose a drop-in file or the main configuration
OpenSSH installations commonly support configuration snippets in /etc/ssh/sshd_config.d/. A dedicated drop-in keeps your hardening rule separate from distribution-managed content and is less likely to be overwritten during a package upgrade. Editing /etc/ssh/sshd_config is also valid when your operating system does not use drop-ins or when your team manages that file centrally.
| Approach | Advantages | Points to check |
|---|---|---|
Drop-in under /etc/ssh/sshd_config.d/ |
Isolated change, easy rollback, and generally upgrade-friendly. | Make sure the directory is included by your packaged configuration and that no existing snippet produces an unexpected effective value. Verify with sshd -T. |
Main /etc/ssh/sshd_config |
Works on installations without a drop-in layout and keeps all policy in one file. | Package updates or configuration-management tools may modify the file. Preserve a backup and check for later active directives. |
If you use a drop-in, an early, descriptive filename such as 00-disable-password-authentication.conf makes the policy easy to find and is intended to take precedence in installations that process snippets in lexical order. Because precedence depends on the complete include layout, confirm the result with sshd -T rather than assuming the filename won.
Apply key-only authentication
The following command creates a root-owned drop-in without opening an editor:
sudo tee /etc/ssh/sshd_config.d/00-disable-password-authentication.conf > /dev/null <<'EOF'
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
EOFEach directive has a deliberate role. The first removes ordinary password authentication; the second preserves key authentication; the third closes the keyboard-interactive route that can still display a password prompt through PAM. Keep the values lowercase and use only yes or no for these boolean options.
If your server does not use the drop-in directory, add the same three active lines to /etc/ssh/sshd_config instead. Do not create two competing policy files while troubleshooting; one clearly owned configuration is easier to audit. Leave UsePAM unchanged unless you have a specific, separately evaluated reason to alter it. PAM also controls other login behavior, and turning it off as a generic password-hardening step can have unintended effects.
Validate before reloading SSH
Always run the daemon’s syntax check before asking the service to reload:
sudo sshd -tNo output and a successful exit status mean the parser accepted the configuration. A printed error identifies a file and line to correct. Do not reload after a failed check. Fix the syntax, rerun sshd -t, and only continue when it succeeds.
Next inspect the effective values:
sudo sshd -T | grep -iE 'passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication'The output should contain:
passwordauthentication no
kbdinteractiveauthentication no
pubkeyauthentication yesIf a value differs, search every included file again, look for another active occurrence, and check that the drop-in directory is actually included. A successful syntax check does not mean the policy is the one you intended; it only means the files are syntactically valid.
Free tools Windows power users keep installed
One-click scans. No signup required.
Reload the correct service
Reloading makes the daemon reread its configuration while normally preserving existing sessions. The service name varies by distribution:
| Common family | Reload command |
|---|---|
| Debian or Ubuntu | sudo systemctl reload ssh |
| RHEL-family systems | sudo systemctl reload sshd |
Use the service name that exists on your VPS. If the reload reports an error, leave the original session connected, inspect the service status and logs, and correct the configuration before trying again. Avoid an unnecessary full restart while you are still proving access; a restart creates a larger interruption window if the daemon cannot start.
Test both the rejection and the intended login
Use the second terminal for all tests. First, force an authentication attempt that does not use your key:
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesssh -o PreferredAuthentications=password -o PubkeyAuthentication=no -o KbdInteractiveAuthentication=no user@serverAfter the policy is active, this attempt should fail rather than offer an account-password prompt. The exact client error varies by OpenSSH version, but the important result is that no password-based method succeeds.
Then make a normal key login, explicitly selecting the key if necessary:
ssh -i ~/.ssh/id_ed25519 user@serverThis connection should succeed without asking for the account password. Test the same username, port, hostname, and private key that your automation or administrators will use. If your client has an SSH configuration in ~/.ssh/config, verify the alias as well as the raw hostname so an incorrect client-side setting does not hide a server-side problem.
Only after the key login succeeds should you close the original session. Keep a successful key session open for a few minutes while checking the effective configuration and service status.
Decide what to do about root SSH access
Password authentication and root login are separate controls. PermitRootLogin accepts yes, prohibit-password, forced-commands-only, or no. The documented default is prohibit-password, which disallows password and keyboard-interactive authentication for root while still permitting key-based root login.
| Setting | Effect for root over SSH | When it fits |
|---|---|---|
PermitRootLogin prohibit-password |
Root cannot use password or keyboard-interactive authentication, but a root key login can remain possible. | Systems that still require carefully controlled root key access. |
PermitRootLogin no |
No direct root SSH login, including key authentication. | Systems where administrators should log in as a named account and elevate with sudo. |
PermitRootLogin forced-commands-only |
Root keys are restricted to forced commands rather than an unrestricted interactive shell. | Narrow automation or backup use cases that have been designed for command restriction. |
PermitRootLogin yes |
Allows root login methods that other authentication settings permit. | Generally avoid unless a specific operational requirement has been assessed. |
If you add a root policy, validate it with the same sshd -t, reload, and second-terminal testing process. Do not set PermitRootLogin no until a non-root account with working key authentication and sudo access has been tested.
Why disabling only PasswordAuthentication can be insufficient
SSH authentication methods are negotiated separately. Setting PasswordAuthentication no removes the method named “password,” but a server that still permits keyboard-interactive authentication can ask the user questions through PAM. On some systems that appears to the user as another password prompt. Setting KbdInteractiveAuthentication no closes that second route.
Distribution packages can also change the effective policy from the upstream daemon defaults. Debian’s packaged configuration, for example, sets some options differently from the defaults documented by OpenSSH, including KbdInteractiveAuthentication no. That is why inspecting both the packaged files and sshd -T is more reliable than copying a setting from another server.
Troubleshoot common outcomes
The client still receives a password prompt
- Run
sudo sshd -T | grep -iE 'passwordauthentication|kbdinteractiveauthentication'and confirm both values areno. - Search all files under
/etc/ssh/sshd_configand/etc/ssh/sshd_config.d/for active duplicate directives. - Confirm the service was reloaded after the edit and that you reloaded the daemon actually serving port 22.
- Check the client test options. A client-side password prompt may be coming from a different host, port, or SSH alias than the server you edited.
The key login fails after the change
- Do not close the original session. Use it to restore the previous drop-in or correct the key configuration.
- Verify that
PubkeyAuthentication yesis effective withsshd -T. - Confirm the key is being offered for the correct username and host; a valid key for one account does not authorize another account.
- If SSH is no longer reachable, use the provider’s out-of-band console or rescue mechanism to run
sshd -t, remove or rename the new drop-in, and reload the service.
The syntax check fails
Read the file and line number in the error, correct the directive or unmatched configuration text, and rerun sudo sshd -t. Do not use a restart as a way to discover syntax errors; validation is safer while your current session remains available.
The reload command says the unit does not exist
The service may be named ssh rather than sshd, or the VPS may use a distribution-specific service manager. Check which SSH service is installed, then run the reload command for that unit. The configuration test remains sudo sshd -t even when the service unit has a different name.
Rollback and recovery
If testing exposes a problem, restore the last known-good policy from the still-open session or provider console. For the drop-in created above, renaming it keeps a copy while removing it from the active include path:
sudo mv /etc/ssh/sshd_config.d/00-disable-password-authentication.conf
/etc/ssh/sshd_config.d/00-disable-password-authentication.conf.disabled
sudo sshd -t
sudo systemctl reload sshUse sshd instead of ssh in the final command on a system whose service unit uses that name. If you edited the main file, restore your backup, run the syntax check, and reload. After recovery, establish a second working key session before attempting the hardening change again.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Completion checklist
- A second terminal authenticated with the intended SSH key before the change.
- The original administrative session remained open during editing, validation, reload, and testing.
PasswordAuthentication nois effective.KbdInteractiveAuthentication nois effective.PubkeyAuthentication yesis effective.sudo sshd -tcompleted successfully before the reload.- The correct service unit was reloaded.
- A forced password-only test failed.
- A normal key-based test succeeded.
- Any chosen
PermitRootLoginpolicy was tested without removing the only administrative route.
Once all ten checks pass, new SSH connections require a public key rather than an account password, while your existing key-based administration path remains available.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
