The lockout scenario
You just finished setting up SSH keys on your Fedora server. You test the connection, it works, and you decide to tighten security by turning off password logins. You edit the config, restart the service, and immediately lose access. The terminal hangs. Your second session refuses to connect. You are now locked out of a machine you cannot physically touch. This happens more often than it should. The fix is straightforward, but the sequence matters. One missed step turns a security upgrade into a recovery project.
What password authentication actually does
OpenSSH handles dozens of authentication methods. Password authentication is the default fallback when key-based login fails or isn't configured. The daemon checks /etc/shadow, prompts for a password, and validates it against the stored hash. It works everywhere, but it exposes your system to brute-force scripts, credential stuffing, and offline dictionary attacks. Disabling it does not break SSH. It simply removes one door. You still need at least one other door open, or you will lock yourself out. The standard alternative is public key authentication. The daemon verifies a cryptographic signature instead of a secret string. It is faster, resistant to guessing, and scales across hundreds of machines without password rotation headaches.
When a client connects, the server sends a list of acceptable methods. The client tries them in order. If you disable passwords but leave key authentication enabled, the server drops the password prompt and waits for a public key. If both are disabled, the connection terminates immediately. Understanding this handshake prevents the panic that comes when a terminal suddenly stops responding.
The fix
Fedora ships OpenSSH with a modular configuration layout. The main file lives at /etc/ssh/sshd_config. You will edit this file directly. Never modify files in /usr/lib/ssh/. Those are package-managed templates. Changes there vanish on the next dnf upgrade. Always work in /etc/.
Before you touch the config, open a second terminal window. Keep an active session alive while you test the new configuration. If you break the connection, the second window gives you a chance to revert.
Here is how to open the configuration file and apply the change.
sudo nano /etc/ssh/sshd_config
# WHY: Opens the daemon config in a terminal editor with root privileges.
# Nano is preinstalled on Fedora Workstation and Server.
Find the line that controls password logins. It is usually commented out by default.
#PasswordAuthentication yes
# WHY: The leading hash disables the directive. OpenSSH falls back to its
# compiled-in default, which is yes. Uncomment and change to no.
PasswordAuthentication no
# WHY: Explicitly disables password prompts for all users.
# Public key authentication remains enabled by default.
Save the file and exit. In nano, press Ctrl+O, then Enter to write, followed by Ctrl+X to quit.
Do not restart the service yet. Validate the configuration syntax first. The sshd binary can parse the file without starting a new daemon. This catches typos before they drop your active connection.
sudo sshd -t
# WHY: Runs a syntax check against the current sshd_config.
# Returns zero exit code on success. Prints line numbers on error.
If the command returns nothing, the syntax is clean. Apply the change.
sudo systemctl restart sshd
# WHY: Reloads the daemon with the new configuration.
# Existing sessions remain active. New connections use the updated rules.
Test the new configuration from a fresh terminal window before closing your original session.
ssh user@your-server-ip
# WHY: Opens a new connection to verify key authentication works.
# Do not close the original window until this succeeds.
Reboot before you debug. Half the time the symptom is gone.
Verify it worked
A successful configuration change leaves no visible trace in the terminal. You need to check the daemon state and attempt a password login to confirm the restriction is active.
Check the service status first.
systemctl status sshd
# WHY: Shows whether the daemon is running, active, and recently restarted.
# Look for "active (running)" and a recent timestamp.
Now test the restriction. Open a new terminal and force password authentication.
ssh -o PreferredAuthentications=password user@your-server-ip
# WHY: Overrides client-side key preferences to force a password prompt.
# This proves whether the server actually rejects password attempts.
The server should refuse the connection immediately. You will see a clear rejection message.
Permission denied (publickey).
# WHY: OpenSSH drops the connection when no acceptable authentication
# methods remain. Password is disabled, so only keys are allowed.
If you see Permission denied (publickey,password), the server still accepts passwords. Check your config file for duplicate directives. OpenSSH reads the first match and ignores the rest.
Run journalctl -xeu sshd to see the exact authentication flow. The x flag adds explanatory context. The e flag jumps to the end of the journal. Most sysadmins type this muscle-memory style when debugging login failures.
journalctl -xeu sshd
# WHY: Pulls recent daemon logs with explanatory notes.
# Look for "Authentication refused" or "Connection closed by authenticating user".
Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls and error messages
The most common failure is a duplicate directive. Fedora's default config includes files from /etc/ssh/sshd_config.d/. If you place PasswordAuthentication no in the main file but a drop-in file in the .d directory sets it to yes, the behavior depends on load order. OpenSSH processes the main file first, then reads drop-ins in alphabetical order. The last matching directive wins.
Check for conflicting drop-ins.
ls -l /etc/ssh/sshd_config.d/
# WHY: Lists any custom configuration fragments that override the main file.
# Drop-ins are the recommended way to manage sshd settings on Fedora.
If you see files there, open them and verify they do not re-enable passwords. The cleanest approach is to put your override in a dedicated drop-in file instead of editing the main config.
sudo nano /etc/ssh/sshd_config.d/99-disable-passwords.conf
# WHY: Creates a high-priority drop-in that loads after default fragments.
# The 99 prefix ensures it overrides earlier settings.
Add the directive inside.
PasswordAuthentication no
# WHY: Explicitly disables password login in the drop-in directory.
# OpenSSH merges this with the base configuration automatically.
Another frequent issue is disabling passwords before key authentication is fully configured. If your ~/.ssh/authorized_keys file has wrong permissions, OpenSSH ignores it silently. The daemon requires strict permissions for security reasons.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
# WHY: Tightens directory and file permissions to meet OpenSSH requirements.
# The daemon refuses to read keys if other users can access them.
You may also encounter PAM interference. Fedora uses ChallengeResponseAuthentication to handle two-factor prompts and smart card logins. If you only disable PasswordAuthentication, PAM can still fall back to password prompts. Disable both to close the gap completely.
PasswordAuthentication no
ChallengeResponseAuthentication no
# WHY: Blocks both direct password checks and PAM-mediated password fallbacks.
# Leaves only public key and certificate authentication active.
If you lock yourself out, you can recover through the console or a rescue environment. Boot into the GRUB menu, press e on the Fedora entry, append rd.break to the linux line, and press Ctrl+X. This drops you into a root shell where you can remount the filesystem read-write and edit the config.
mount -o remount,rw /sysroot
chroot /sysroot
nano /etc/ssh/sshd_config
# WHY: Remounts the root filesystem for writing and switches to the real system.
# Allows direct config edits when network access is broken.
Revert the change, run exec /sbin/init, and let the system boot normally. Keep a known-good backup of your SSH config. Future-you will thank you.
When to disable passwords versus alternatives
Use password authentication when you are managing a small home lab and convenience outweighs strict security requirements. Use key-based authentication when you are running production services or accessing machines over the public internet. Use PasswordAuthentication no when you have verified that every administrative account has a working key pair. Use ChallengeResponseAuthentication no alongside it when you want to block PAM-based password fallbacks that bypass the main directive. Stay on the default configuration if you only need basic remote access and do not manage multiple servers.