When supplying Unix authentication credentials, you must include a user account to be used by the scanning engine to log into target hosts. You may also supply a password for the user account, an RSA private key, and a DSA private key. When authenticating to target hosts that support SSH2, authentication is attempted in the following order: 1) RSA key, 2) DSA key and 3) password. For target hosts that only support SSH1, only the supplied user name and password are used for authentication.
During authenticated vulnerability scans, the scanning engine is able to access patch history and system configuration information for target hosts, increasing the number of vulnerabilities that may be detected.
When the compliance module is enabled, users with compliance privileges can launch compliance scans to identify whether hosts are compliant with user-defined policies. Successful authentication to target hosts is required for compliance scans. In this case, Unix authentication must be performed with superuser (root) privileges.
For vulnerability scanning, the user account provided for authentication must be able at a minimum to execute these commands:
• The account must be able to execute "uname" in order to detect the platform for packages.
• If the target is running Red Hat, the account must be able to read /etc/redhat-release and execute "rpm".
• If the target is running Debian, the account must be able to read /etc/debian-version and execute "dpkg".
The service sends many more commands than those listed above to perform information gathering and vulnerability assessment. The specific commands used vary over time as the vulnerability signatures and scanning engine are updated, and improvements are made to the service. Contact our Support team for a list of commands used during authenticated scanning.
For compliance scanning, the user account provided for authentication must have superuser (root) privileges (or lower privileges if root delegation is enabled). If root privileges are not provided or if authentication to hosts fails, then no controls can be evaluated for the host and no compliance data can be collected for the host. If authentication to a host is successful, then the host can be evaluated for compliance.
For both vulnerability and compliance scanning, you can provide a lower-privileged user account for authentication if you enable root delegation in the Unix authentication record. The service supports these root delegation tools: Sudo and PowerBroker. When a root delegation tool is enabled in a Unix authentication record and properly configured on target hosts, the scanning engine authenticates to target hosts using the lower-privileged user account and performs scan tests with the elevated privileges of the superuser (root). See Enable Root Delegation for more information and configuration requirements.
Basic authentication (user name and password) is supported for SSH1 and SSH2. For basic authentication to be successful, the user account must be added to all target hosts. The corresponding user name and password must be supplied in an authentication record.
Key authentication is supported for SSH2 only. The service supports RSA and DSA keys generated with any version of OpenSSH that supports SSH protocol version 2 (SSH2). The private keys must be PEM-encoded (the standard for OpenSSH), and must not be encrypted with a passphrase, meaning that the passphrase is empty.
For key authentication to be successful, the user account must be added to all target hosts along with the public key, which will be appended to the ".ssh/authorized_keys2" file in the user's home directory. The private key is supplied in an authentication record.
Important! The scanning engine must have full access to the target hosts during scanning in order to perform security assessments. It is possible that manually added options in ".ssh/authorized_keys2" files (like no-pty) lockout the scanning engine so security tests cannot be performed. Before you begin, ensure that the scanning engine has full, unrestricted access to the target hosts. If you are troubleshooting the reason why a scan did not return expected results, it is recommended that you remove the additional, manually added options from the scanning account's public key in the ".ssh/authorized_keys2" files and scan the target hosts again to confirm whether the scanning engine can authenticate to hosts and perform scanning.
See the following for more information:
Generate an SSH key pair using OpenSSH
Once you've defined a user account to be used for authentication, it's time to add a Unix authentication record. See Creating Unix Records for instructions.