SSH Password Authentication Accepted means the SSH server still lets users log in with a password, which exposes it to password guessing and reused credentials. To disable SSH password authentication, confirm key-based login works, set PasswordAuthentication no and KbdInteractiveAuthentication no in sshd_config, check /etc/ssh/sshd_config.d/ for overrides, then test and restart sshd.
What the scanner is actually detecting
The finding comes from Tenable Nessus plugin 149334, titled SSH Password Authentication Accepted, in the Service detection family. Tenable’s description is a single line: the SSH server on the remote host accepts password authentication. Tenable classifies it as a remote check with severity Info. The accepted-methods list is available before authentication, so no scan credentials should be needed.
Tenable does not publish the plugin logic, but the signal is simple. Before any login succeeds, an SSH server tells the client which authentication methods it will accept. OpenSSH prints that list in brackets when a login fails, for example Permission denied (publickey,password). If password is in the list, the server accepts passwords.
This guide also covers keyboard-interactive authentication. On most Linux systems it is handled by PAM and prompts for the same account password, so disabling only PasswordAuthentication can leave password logins working through a second door.
How serious is it?
An Info rating is fair: accepting passwords is a configuration choice, not a software flaw. The real risk depends on exposure and password hygiene. An SSH service that accepts passwords can be hit by automated guessing, password spraying and logins with credentials leaked from unrelated breaches, and internet-facing SSH ports receive that kind of traffic continuously. Key-based authentication removes this class of attack, because there is no shared secret to guess or reuse.
On an internal host with strong unique passwords, the risk is lower, but password SSH remains an easy lateral movement path once an attacker holds one working credential inside the network.
How to confirm it on the host
Ask sshd for its effective configuration instead of reading files. sshd -T parses every included file and prints the values it will use:
sudo sshd -T | grep -Ei '^(passwordauthentication|kbdinteractiveauthentication|challengeresponseauthentication|usepam)'If you see passwordauthentication yes, the finding is valid. Next, find where the value comes from. Check whether the main file includes a drop-in directory, then list every definition, including Match blocks:
grep -i '^Include' /etc/ssh/sshd_config
sudo grep -RinE '^s*(PasswordAuthentication|KbdInteractiveAuthentication|ChallengeResponseAuthentication|Match)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/From another machine, you can see what the scanner sees. With public key and interactive prompts disabled on the client, the login fails and prints the methods the server offers:
ssh -o BatchMode=yes -o PubkeyAuthentication=no -o StrictHostKeyChecking=accept-new user@host
# user@host: Permission denied (publickey,password).The accept-new option matters: BatchMode disables host key prompts, so a client that has never seen this server would print Host key verification failed. instead of the method list.
How to fix it
Step 1: prove key-based login works
Before you change anything, log in with a key for every account that needs SSH access, including service and automation accounts. Keep one root session or console (hypervisor, cloud serial console, iLO/iDRAC) open until you have finished testing. Red Hat’s documentation gives the same warning.
Step 2: understand the first-value rule
The sshd_config man page states that, unless noted otherwise, the first value obtained for each keyword is the one used. Ubuntu puts Include /etc/ssh/sshd_config.d/*.conf at the very top of /etc/ssh/sshd_config, and included files are processed in lexical order. So a drop-in file wins over the main file, and 00-name.conf wins over 50-name.conf. This is the usual reason people report that PasswordAuthentication no is not working: they edited the main file while a drop-in had already set yes.
Step 3a: OpenSSH 8.7 and later (Ubuntu 22.04, Debian 12, RHEL 9 and newer)
If sshd_config has the Include line, create a drop-in that sorts first:
sudo tee /etc/ssh/sshd_config.d/00-disable-password-auth.conf >/dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
EOFIf there is no Include line, edit /etc/ssh/sshd_config directly and set the same two directives. Place them above any Match block: the man page explains that keywords after a Match line apply only to that match, until the next Match line or the end of the file.
Step 3b: older OpenSSH (before 8.7)
In OpenSSH 8.7, ChallengeResponseAuthentication became a deprecated alias of KbdInteractiveAuthentication. Before 8.7 they were separate options, and ChallengeResponseAuthentication (default yes) turns keyboard-interactive on regardless of KbdInteractiveAuthentication. So on older versions, such as those shipped with RHEL 8, Ubuntu 20.04 or Debian 11, set all three directives:
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication noThe third line matters because the link works only one way. ChallengeResponseAuthentication yes forces keyboard-interactive on, but no does not force it off: if any file sets KbdInteractiveAuthentication yes, PAM password prompts stay available. Where to put the lines depends on the main file:
- If sshd_config has the Include line (Ubuntu 20.04, Debian 11), put these three lines in /etc/ssh/sshd_config.d/00-disable-password-auth.conf, as in step 3a. The first-value rule and any 50-cloud-init.conf drop-in apply here too.
- Otherwise (RHEL 8), change the existing lines in /etc/ssh/sshd_config and keep them above any
Matchblock.
Check the version with rpm -q openssh-server or dpkg -l openssh-server; sshd -T alone does not tell you, because older builds print both keywords. The verification steps below work on every version.
Step 3c: cloud-init images (Ubuntu 22.04 and others)
When sshd_config includes the drop-in directory, cloud-init’s Set Passwords module writes its ssh_pwauth setting to /etc/ssh/sshd_config.d/50-cloud-init.conf. If that file contains PasswordAuthentication yes, it overrides the main file. The 00- drop-in already wins, but clean up the source too so new instances built from the same template do not bring it back:
sudo sed -i 's/^PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config.d/50-cloud-init.conf
echo 'ssh_pwauth: false' | sudo tee /etc/cloud/cloud.cfg.d/99-disable-ssh-pwauth.cfgAlso remove ssh_pwauth: true from the user-data in your VM templates, Terraform or other provisioning code.
Step 4: test the config and restart
Validate before restarting; sshd -t checks the configuration without touching the running service:
# Debian and Ubuntu
sudo sshd -t && sudo systemctl restart ssh.service
# RHEL, Rocky Linux, AlmaLinux, Fedora
sudo sshd -t && sudo systemctl reload sshdHow to verify the fix and rescan
- Check the effective values:
sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractiveauthentication'should printnofor both. - If you use Match blocks, test them too. The
-Coption applies Match rules for a given connection:sudo sshd -T -C user=deploy,host=scanner.example.com,addr=10.0.0.50 | grep -i passwordauthentication. Use the address of your scanner. - From a client, repeat the BatchMode
sshtest from the confirmation section. The method list should no longer containpasswordorkeyboard-interactive, for examplePermission denied (publickey).On RHEL-family systems, whereGSSAPIAuthentication yesis on by default (in /etc/ssh/sshd_config.d/50-redhat.conf on RHEL 9 and later, in /etc/ssh/sshd_config on RHEL 8), expectPermission denied (publickey,gssapi-keyex,gssapi-with-mic). - Open a new session with your key to make sure you can still get in, before closing the old one.
- Rerun the Nessus scan against the host. Because Tenable classifies plugin 149334 as a remote check, a normal scan should be enough. Make sure your report filter shows Info findings, or you will not be able to tell whether it cleared.
What can break and how to roll back
- Users without keys are locked out of SSH. Distribute keys first.
- Automation that logs in with passwords, such as scripts using sshpass, password-based Ansible inventories, backup jobs and SFTP transfers, will fail.
- Credentialed vulnerability scans configured with an SSH password will stop authenticating and quietly lose coverage. Switch the scan credential to a key; see our guide to running authenticated Linux scans over SSH with sudo.
- PAM-based MFA that runs through keyboard-interactive will stop working if you disable KbdInteractiveAuthentication. In that case, keep it enabled and require keys plus the second factor with
AuthenticationMethods publickey,keyboard-interactive. With that setting andPasswordAuthentication no, the server no longer offers password as a standalone method, so the finding should clear on rescan. If it does not, document it as a reviewed exception.
To roll back, use the session or console you kept open, remove or edit the file you changed, validate and restart:
sudo rm /etc/ssh/sshd_config.d/00-disable-password-auth.conf
sudo sshd -t && sudo systemctl restart ssh.service # or: systemctl reload sshdIf you back up files inside /etc/ssh/sshd_config.d/, do not give the copy a name ending in .conf, or sshd will include it.
Common false positive reasons
- A Match block re-enables passwords for certain users or source addresses. If the scanner’s IP falls inside a
Match Addressrange that allows passwords, the finding is accurate for the scanner despite the global setting. - The scanner reached a different SSH service, such as a network appliance, a container publishing port 22, a second daemon on another port, or a load balancer in front of the host.
- The change was never applied: sshd was not restarted or reloaded, only one cluster node was updated, or the report predates the change. Rescan before closing or disputing the finding.
- Passwords are intentional on a bastion or vendor access host. That is not a false positive; document it as an accepted risk with compensating controls.
FAQ
Does PasswordAuthentication no affect sudo or local console logins?
No. It only controls how sshd authenticates remote SSH logins. sudo, su and console logins still use the account password through PAM.
Why does sshd_config say no, but the scan still reports passwords?
Usually because another file sets the value first, typically /etc/ssh/sshd_config.d/50-cloud-init.conf, or a Match block applies to the scanner. Run sshd -T to see the effective value.
Is PermitRootLogin prohibit-password enough?
No. It blocks password logins for root only. Every other account can still log in with a password, so the plugin will still report the host.
Are KbdInteractiveAuthentication and ChallengeResponseAuthentication the same?
On OpenSSH 8.7 and later, yes: ChallengeResponseAuthentication is a deprecated alias for KbdInteractiveAuthentication. On older builds they are separate options, and ChallengeResponseAuthentication, which defaults to yes, enables keyboard-interactive on its own. Use the new name on current systems; on older builds, set both to no.
Tracking this finding across many hosts
On a large Linux estate, this finding tends to come back whenever a new VM is built from an old template, so it helps to track it centrally. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners, including Nessus results uploaded as .nessus exports, and supports per-finding retest for Nessus findings. It can also generate host-specific remediation scripts that pass human approval gates before its agents apply them on Linux endpoints, then re-test to confirm the finding is closed.