Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm testing out both Tenable's Nessus scanner as well as eEye's Retina for scanning network devices. I am trying to supply credentials to get deeper, more accurate results, however there seems to be no difference in the results whether I supply the credentials or not. I've read the documentation and it seems like I've tried all the logical settings in the Credential options. I've submit along with usernames and passwords for many different accounts and types of accounts (both SSH Credentials and Web Application Credentials) on the devices as well as their respective domain names (when applicable).

Is there possibly a good test for either (or both) scanners to tell where these credentials are being provided (if at all) and if any of them are successfully getting authentication?

share|improve this question
What OS is the client? – Scott Pack Sep 21 '10 at 23:26
The OS is Linux. – grossmae Sep 21 '10 at 23:34
unless you have a single pw for all the linux devices the authentication willl not perform well, the tennable version of nessus works fine against a windows based domain when you provide an account with admin privs on the devices your scanning – tony roth Sep 22 '10 at 0:35
I am only scanning one device at the moment, so the credentials are essentially all identical. – grossmae Sep 22 '10 at 1:24
so do you run the test with an account that has root? When we run nessus against our windows server it has admin privs on the device that we are scanning. Its unfair but does expose everything! Windows 08+ when scanned with admin privs show's no vuln's worth mentioning.. – tony roth Sep 23 '10 at 3:06

If you are scanning some windows systems you can check the security event log to see if the authentication attempts from the scanner were valid or not. If the connection attempts from the scanners were authenticated then the scanners had access provided by the credentials, now whether the scanners were configured properly to "scan deeper" is another issue.

share|improve this answer
I'm not scanning any windows systems. Network logs from the device are not easily reachable and probably won't provide very much information. I have been using wireshark to sniff for credentials being passed, but I cannot find any. Are there perhaps some techniques to find packets with credentials other than searching for string values? – grossmae Sep 22 '10 at 0:20

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:

  1. 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.
  2. 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'.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.