Set Up Unix Authentication

Configure Unix records to allow our service to authenticate to your Unix hosts at scan time. Now, you can configure a single authentication record that supports better integration with third-party vaults and lets you define a variety of private keys and root delegation tools.

Notes:

- For Unix authentication scan, the scanner requires opening multiple shell sessions. Make sure that the security configuration of the SSH service permits the scanner to initiate multiple shell sessions for the Unix authentication scan.

- FIPS requires private keys in PKCS8 format. If you encounter any issues while creating or updating an existing authentication records that use  private keys with or without a passphrase, update or create new authentication records with private keys in PKCS8 format. 

Update Existing Private Keys: Update the existing private keys by converting them to PKCS8 format.

Create New Private Keys: Create new private keys in PKCS8 format.

This ensures compatibility with FIPS requirements and maintains secure authentication records. Ensure that all future private key operations adhere to the PKCS8 standard to maintain FIPS compliance.

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

 

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.

Kerberos is a network authentication protocol designed to provide secure and encrypted authentication for your systems and services. You can specify Kerberos authentication details and perform authenticated scans on Unix systems that have Kerberos (GSSAPI) enabled.

Turn on the Use Kerberos toggle and specify the following details for realm discovery and authentication:

Parameter

Description

Realm Discovery

Specify the realm discovery method. The available values are manual, single, and DNS.

User Realm

Specify the name of the realm that a user belongs to and the KDC (Key Distribution Center) that is responsible for authenticating users and issuing ticket-granting tickets (TGTs) for the realm.

User KDC

Service Realm

When a user wants to access a service that is part of a different realm, specify:

- The name of the realm that a service belongs to.

-  The KDC that manages authentication for the service in its realm.

Service KDC 

Authentication Type

Specify the authentication type. Only basic or vault-based authentication is supported for Kerberos.

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).

For compliance scans, root level privileges are required. For vulnerability scans, root level privileges are not required. If you do not want to use root level privileges for vulnerability scans, then edit your vulnerability scan option profile and select the scan option Attempt least privilege for Unix (skip root delegation in Unix record). Learn more

Using sudo and dzdo 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.

If your subscription has Tag Support for Authentication Records enabled, then you'll see additional options for specifying hosts using asset tags. Choose an asset type and then provide IPs or tags to the record. Your asset type options are: IPs/Ranges, IP Range in Tag Rule and Asset Tags.

Asset Type: IPs/Ranges - Use this option to add IP addresses/ranges to the record. Enter the IP addresses/ranges in the field provided.

Asset Type: IP Range in Tag Rule - Use this option to add tags that have IP address ranges defined in the tag rule. All IP addresses defined in the tag rule will be associated with the record, including IPs that don’t already have the tag assigned. Click Add Tag to pick tags to include or exclude. Note that only tags with the dynamic tag rule “IP Address in Range(s)” will be available in the tag selector.

Asset Type: Asset Tags - Use this option to add tags to the record for the assets you want included. IP addresses with the selected tags already assigned will be associated with the record. Click Add Tag to pick tags to include or exclude.

Learn more about tag support for authentication records

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 portsTell me more about scanned ports

If Standard Scan is selected in the compliance profile, then these ports will be scanned: the standard ports list (about 1900 ports) provided by the service, including ports 22, 23 and 513, plus the custom ports specified in the authentication record.

If Targeted Scan is selected in the compliance profile, then these ports will be scanned: the custom ports specified in the authentication record only (no other ports).

Refer to the table below:

Compliance Profile

Authentication Record

Ports Scanned

Standard Scan

Well Known Ports

~1900 Ports (includes Ports 22, 23, 513)

Standard Scan

Custom Ports

~1900 Ports + Custom Ports in record

Targeted Scan

Well Known Ports

Ports 22, 23 and 513 only

Targeted Scan

Custom Ports

Custom Ports in record only

 

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.

Quick Links

Why use host authentication

Unix login credentials

Tag Support for Authentication Records

Arista EOS

ArubaOS

ArubaOS Switch

ArubaOS CX

Junos OS

FortiOS

Huawei

IBM z/OS Security Server RACF 

Generic Linux

NetApp Ontap

F5 Load Balancer authentication

Supported Private Keys/Certificates

OPatch Checks

Cisco CUCM

How to prevent BASH history file from filling up

Unix Auth PDF Icon

NetScaler Auth PDF Icon

A10 Auth PDF Icon

IBM VIOS Auth PDF Icon

Scan Check Point with Gaia Clish

Limitation of Control(s) Scannable Using Non-Expert Mode Shell

Private Keys / Certificates

OpenSSH-encoded private keys

PEM-encoded private keys

OpenSSH certificates

PEM-encoded certificates

From the Community

*NIX Authenticated Scan Process and Commands