Attempting to debug authentication problems in automated systems can certainly be tricky. While authentication isn't the first thing the scanner tries, it is fairly early in the scan process. What the system does is kick off a port scan looking at a handful of the most common ports, and if the remote authentication ports are open it will attempt to authenticate and run the credentialed checks. On Windows this would be TCP port 445, and on Linux/Unix TCP port 22.
There are a lot of things that can go wrong with this kind of authentication, so these are the steps I would try:
- Are you authenticating but unable to run the remote checks? Use the fancy filtering system and look for PluginID 21745. This is kind of a meta-plugin that tests to see if the scanner failed to authenticate. If this plugin is in your report, then authentication failed. This is a nice, fast, way to prove our initial assumption that we failed to authenticate.
- Does your scan policy include any local checks? From the web interface open the policy you're using, select the 'Plugins' tab, and add the filter 'Plugin Type -> is equal to -> local'.
- Check your scan report to make sure that port 22 is listed as open. If not, then you'll need to check the host's firewall settings, and possibly
/etc/ssh/sshd_config
.
- Check to see if the user itself can login to the remote host. From the Nessus scanner try
ssh nessususer@remotehost.tld
and see if you can actually authenticate. If your username and password still don't work, then the sysadmin needs to get involved to fix the user on the remote host.
- Is the remote host expecting key based auth instead of password? If so, then make sure the public key has been placed correctly into the
authorized_key
file on the remote host. Remember, the public key must be a single line per entry (be wary of introducing new lines from copy/pasting) and that the permissions are appropriately strict on the .ssh
folder.
- Look at your scan profile. If you had copied this profile from another scanner, or had created it as a copy of an existing profile, then the saved passwords probably didn't come with it. Import them again.
- If all of this fails, I would try contacting support. Since you're paying for the ProfessionalFeed (and based on the assumptions in the FAQ you're violating your license otherwise) you can file a ticket in same place you get your activation key.
All that being said, I can't say that I've ever tried to use password authentication for the credentialed Linux/Unix checks. The system may very easily be assuming public/private key pairs.