Set Up Network SSH Authentication

Configure Network SSH records to allow our service to authenticate network devices (such as Cisco and Checkpoint Firewall) using SSH2 authentication format. Network SSH authentication record can be used in place of the Cisco and Checkpoint Firewall authentication records.

Which technologies are supported?

For the most current list of supported authentication technologies and the versions that have been certified for VM and PC by record type, please refer to the following article:

Authentication Technologies Matrix

A few things to consider...

What credentials should I use?What credentials should I use?

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

Where can I find a list of commands?Where can I find a list of commands?

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.

Help me with the record settings

How do I get started?How do I get started?

- Go to Scans > Authentication.

- Create a Unix record for the host. Go to New > Network and Security > Network SSH.

What do I enter for Login Credentials?What do I enter for Login Credentials?

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.

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

Enable/Expert Password - If the "enable" or "expert" command on the target host requires a password, then you must also provide the enable or expert password in the record. (Note: The pooled credentials feature is not supported if the "enable" or "expert" command requires a password and the password is specified.).

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

Using Private Keys / CertificatesUsing Private Keys / Certificates

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

Tips for successful authentication using private keys/certificatesTips for successful authentication using private keys/certificates

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.

Good to Know - Private Keys and Certificates are now stored separatelyGood to Know - Private Keys and Certificates are now stored separately

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.

Which IPs should I add to my record?Which IPs should I add to my record?

Select the network devices IPs to authenticate to. The IPs you include in this record cannot also be included in a Unix, Cisco or Checkpoint Firewall record.

Important Notes for Unit ManagersImportant Notes for Unit Managers

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.