Set Up Unix Authentication

This depends on the type of scanning you plan to do. If you're going to run vulnerability scans only, the account you provide must be able to execute certain commands. If you're going to run compliance scans, superuser (root) privileges are needed in order to evaluate all compliance checks. Learn more

The article *NIX Authenticated Scan Process and Commands describes the types of commands run, and gives you an idea of the breadth and scope of the commands executed. It includes a list of commands that a Qualys service account might run during a scan. Not every command is run every time, and *nix distributions differ. This list is neither comprehensive nor actively maintained.

- Go to Scans > Authentication.

- Create a Unix record for the host. Go to New >Operating Systems > Unix.

You must provide a user name and password to be used for login. There's an option to get the password from a vault that's configured in your account.

Skip Password - Select this option if your login account does not have a password.

Clear Text Password - Select this option if your password should be transmitted in clear text when connecting to services which do not support strong password encryption. Learn more

For target hosts that only support SSH1, only the user name and password are used for authentication.

Provide a target type while creating or updating the Unix (SSH2) authentication record. With this field, you can define the non-shell based target types in the SSH2 authentication record. Targets with a standard Unix shell will continue to be auto-detected. The target type is set to "Auto (default)" in this case. Newly supported target types will be added to the Target Type menu.

You can use multiple private keys and/or certificates for authentication. Any combination of private keys (RSA, DSA, ECDSA, ED25519) and certificates (OpenSSH, X.509).

Private key authentication is supported for SSH2 only.  All of the private keys can either be unencrypted or encrypted with a passphrase.

Tip - If you have multiple private keys/certificates you can sort the order in your record. We'll use the private keys/certificates in the order listed.

Options to get key info from vault:

- Get private key from vault you've configured.

- Get private key passphrase from vault you've configured.

Looking for more help?

Supported Private Keys/Certificates

How to distribute your public key

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.

Important - Our service must have full access to the target hosts during scanning. It is possible that manually added options in “.ssh/authorized_keys2” files (like no-pty) lockout our service and in this case security tests cannot be performed.

Troubleshooting tips

If you are looking into 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 our service can authenticate to hosts and perform scanning.

In previous releases the RSA/DSA key fields in the UI allowed you to enter a key and certificate in the same input field. We've separated these elements in the UI starting with release 8.9.

Did you create Unix  records with private keys and certificates prior to release 8.9? If yes these will now show up in their respective fields separately.

You can use multiple root delegation tools for authentication: Sudo, Pimsu and PowerBroker. There's an option to get password for root delegation from a vault you've configured.

Tip - If you have multiple tools you can arrange the tools in a particular order in the authentication record. We'll attempt each root delegation method in sequence, depending on the order configured.

By enabling root delegation you can provide a lower-privileged user account in the record and still perform scan tests with the elevated privileges of the superuser (root).

Using Sudo for root delegation

Using PowerBroker for root delegation

Select the Unix hosts (IPs) to authenticate to. The IPs you include in this record cannot also be included in a Cisco or Checkpoint Firewall record.

Our security service needs to find login services in order to successfully authenticate to Unix hosts and perform compliance assessment. By default, these well-known ports are scanned: 22 (SSH), 23 (telnet) and 513 (rlogin). Any one of these services is sufficient for authentication. If services (SSH, telnet, rlogin) are not running on well-known ports for the hosts you will be scanning, then you must define a custom ports list.

Note: The actual ports scanned also depends on the Ports setting in the compliance option profile used at scan time.

Tell me more about scanned ports

Select the option "Enable agentless tracking" to track the hosts in this record by host ID. During the scanning process, the service assigns a unique host ID to each target host. Learn more

Don't see this option? The Agentless Tracking feature must first be accepted at the subscription level by the Manager primary contact. This feature is not available to Express Lite users.

Password based authentication to a TACACS server is supported. This server follows the SSH user authentication specification.

When a Unit Manager edits a record, the Unit Manager only sees the IPs in the record that they have permission to. Any changes made by the Unit Manager will apply to all hosts defined in the record, regardless of whether all hosts belong to the user's business unit. The record may contain more IPs that are not visible to the Unit Manager.