When you are running those vulnerability scans of Linux and UNIX hosts I hope that you are following best practices for keeping a host secure during the process. Both Retina and Nessus rely upon SSH in order to connect to a remote host and run a number of commands to compare the querys to their respective databases of known issues, vulns and configuration faults. Removing the directive in the sshd_config file to enable root login is definitely not best practice, and is borderline “hacking naked”. Lucky for us both Tenable and eEye have documented the methods for running scans with su or sudo (the latter preferred).

• Retina: How to enable SUDO support for Retina
• Nessus Spotlight: su+sudo Feature

As the Retina publication states, you may want to limit the commands that the sudo user may run. To do this you can look at the Retina logs on your Windows client; or after a successful scan with take a peek at the NIX user history in order to determine what commands were run. This could also be useful for scripting up a self-scan for a host that may lack a SSH service. Another method may beside reviewing the scanners logs might be to check the history of the secure or messages log to determine what commands were run and successfully returned a response.

After determining what commands the host needs to correctly run a credentialed scan you can limit the users sudo privileges in the /etc/sudoers file. This allows users bob and alice to execut cmd0, cmd1 and cmdn, though disables su and the ability to change to a shell that may not log correctly.

Cmnd_Alias    SHELLS = /usr/bin/sh,  /usr/bin/csh,   
/usr/bin/ksh, /usr/local/bin/tcsh,   
/usr/bin/rsh, /usr/local/bin/zsh
Cmnd_Alias    RETINA = /usr/sbin/cmd0, /usr/sbin/cmd1, /usr/sbin/cmdn
User_Alias    RETINA_USERS = alice, bob
RETINA_USERS  ALL = !/usr/bin/su, !SHELLS, RETINA

As usual, YMMV so let me know if this is helpful or misinforming.