SSH

Use SSH credentials for host-based checks on Unix systems and supported network devices. Nessus uses these credentials to obtain local information from remote Unix systems for patch auditing or compliance checks. Nessus uses Secure Shell (SSH) protocol version 2 based programs (e.g., OpenSSH, Solaris SSH, etc.) for host-based checks.

Nessus encrypts the data to protect it from being viewed by sniffer programs.

Note: Non-privileged users with local access on Linux systems can determine basic security issues, such as patch levels or entries in the /etc/passwd file. For more comprehensive information, such as system configuration data or file permissions across the entire system, an account with root privileges is required.

Note: You can add up to 1000 SSH credentials in a single scan. For best performance, Tenable recommends adding no more than 10 SSH credentials per scan.

See the following settings for the different SSH authentication methods:

There are four settings for SSH credentials that apply to all SSH Authentication methods.

Option Default Value Description

known_hosts file

none

If an SSH known_hosts file is available and provided as part of the Global Credential Settings of the scan policy in the known_hosts file field, Nessus attempts to log into hosts in this file. This can ensure that someone does not use the same username and password you are using to audit your known SSH servers to attempt a log into a system that may not be under your control.

Preferred port

22

You can set this option to direct Nessus to connect to SSH if it is running on a port other than 22.

Client version

OpenSSH_5.0

Specifies which type of SSH client Nessus impersonates while scanning.

Attempt least privilege

Cleared

Enables or disables dynamic privilege escalation. When enabled, Nessus attempts to run the scan with an account with lesser privileges, even if you enable the Elevate privileges with option. If a command fails, Nessus escalates privileges. Plugins 102095 and 102094 report which plugins ran with or without escalated privileges.

Note: Enabling this option may increase scan run time by up to 30%.

Public Key Encryption, also referred to as asymmetric key encryption, provides a more secure authentication mechanism by the use of a public and private key pair. In asymmetric cryptography, Nessus uses the public key to encrypt data and Nessus uses the private key to decrypt it. The use of public and private keys is a more secure and flexible method for SSH authentication. Nessus supports both DSA and RSA key formats.

Like Public Key Encryption, Nessus supports RSA and DSA OpenSSH certificates. Nessus also requires the user certificate, which is signed by a Certificate Authority (CA), and the user’s private key.

Note: Nessus supports the openssh SSH public key format (pre-7.8 OpenSSH). Nessus does not support the new OPENSSH format (OpenSSH versions 7.8+). To check which version you have, check your private key contents. openssh shows -----BEGIN RSA PRIVATE KEY----- or -----BEGIN DSA PRIVATE KEY-----, and the new, incompatible OPENSSH shows -----BEGIN OPENSSH PRIVATE KEY-----. You must convert non-openssh formats, including PuTTY and SSH Communications Security, to the openssh public key format.

The most effective credentialed scans are when the supplied credentials have root privileges. Since many sites do not permit a remote login as root, Nessus can invoke su, sudo, su+sudo, dzdo, .k5login, or pbrun with a separate password for an account that you set up to have su or sudo privileges. In addition, Nessus can escalate privileges on Cisco devices by selecting Cisco ‘enable’ or .k5login for Kerberos logins.

Note: Nessus supports the blowfish-cbc, aes-cbc, and aes-ctr cipher algorithms. Some commercial variants of SSH do not have support for the blowfish algorithm, possibly for export reasons. It is also possible to configure an SSH server to accept certain types of encryption only. Check your SSH server to ensure that it supports the correct algorithm.

Nessus encrypts all passwords stored in policies. However, Tenable recommends using SSH keys for authentication rather than SSH passwords. This helps ensure that someone does not use the same username and password you are using to audit your known SSH servers to attempt a log into a system that may not be under your control.

Note: For supported network devices, Nessus only supports the network device’s username and password for SSH connections.

If you have to use an account other than root for privilege escalation, you can specify it under the Escalation account with the Escalation password.

Option Description

Username

Username of the account which is being used for authentication on the host system.

Private Key

RSA or DSA private key of the user.

Private key passphrase

Passphrase of the private key.

Elevate privileges with

Allows for increasing privileges once authenticated.
Option Description

Username

Username of the account which is being used for authentication on the host system.

User Certificate

RSA or DSA certificate file of the user.

Private Key

RSA or DSA private key of the user.

Private key passphrase

Passphrase of the private key.

Elevate privileges with

Allows for increasing privileges once authenticated.

CyberArk is a popular enterprise password vault that helps you manage privileged credentials. Nessus Manager can get credentials from CyberArk to use in a scan.

Option Description Required

CyberArk Host

The IP address or FQDN name for the CyberArk AIM Web Service.

yes

Port

The port on which the CyberArk API communicates. By default, Nessus uses 443.

yes

AppID

The Application ID associated with the CyberArk API connection.

yes
Client Certificate The file that contains the PEM certificate used to communicate with the CyberArk host.

no
Client Certificate Private Key The file that contains the PEM private key for the client certificate.

no
Client Certificate Private Key Passphrase The passphrase for the private key, if required.

yes, if private key requires
Get credential by The method with which your CyberArk API credentials are retrieved: Username, Identifier, or Address yes
Username

(If Get credential by is Username) The username of the CyberArk user to request a password from.

 no
Safe

(If Get credential by is either Username, Identifier, or Address) The CyberArk safe the credential should be retrieved from.

 no
Account Name (If Get credential by is Identifier) The unique account name or identifier assigned to the CyberArk API credential. no

Use SSL

If enabled, the scanner uses SSL through IIS for secure communications. Enable this option if CyberArk is configured to support SSL through IIS.

no

Verify SSL Certificate

If enabled, the scanner validates the SSL certificate. Enable this option if CyberArk is configured to support SSL through IIS and you want to validate the certificate.

no

The following is the legacy CyberArk authentication method.

Option Description

Username

The target system’s username.

CyberArk AIM Service URL

The URL of the AIM service. By default, this field uses /AIMWebservice/v1.1/AIM.asmx.

Central Credential Provider Host

The CyberArk Central Credential Provider IP/DNS address.

Central Credential Provider Port

The port on which the CyberArk Central Credential Provider is listening.

Central Credential Provider Username

If you configured the CyberArk Central Credential Provider to use basic authentication, you can fill in this field for authentication.

Central Credential Provider Password

If you configured the CyberArk Central Credential Provider to use basic authentication, you can fill in this field for authentication.

Safe

The safe on the CyberArk Central Credential Provider server that contained the authentication information you would like to retrieve.
CyberArk Client Certificate The file that contains the PEM certificate used to communicate with the CyberArk host.
CyberArk Client Certificate Private Key The file that contains the PEM private key for the client certificate.
CyberArk Client Certificate Private Key Passphrase (Optional) The passphrase for the private key, if required.

AppId

The AppId that has been allocated permissions on the CyberArk Central Credential Provider to retrieve the target password.

Folder

The folder on the CyberArk Central Credential Provider server that contains the authentication information you would like to retrieve.

PolicyId

The PolicyID assigned to the credentials you would like to retrieve from the CyberArk Central Credential Provider.

Use SSL

If you configured the CyberArk Central Credential Provider to support SSL through IIS, select this for secure communication.

Verify SSL Certificate

Select this if you configured CyberArk Central Credential Provider to support SSL through IIS and you want to validate the certificate. Refer to the custom_CA.inc documentation for how to use self-signed certificates.

CyberArk Account Details Name

The unique name of the credential you want to retrieve from CyberArk.

CyberArk Address

The domain for the user account.

CyberArk Elevate Privileges With

The privilege escalation method you want to use to increase the user's privileges after initial authentication. Your selection determines the specific options you must configure.

Kerberos, developed by MIT’s Project Athena, is a client/server application that uses a symmetric key encryption protocol. In symmetric encryption, the key used to encrypt the data is the same as the key used to decrypt the data. Organizations deploy a KDC (Key Distribution Center) that contains all users and services that require Kerberos authentication. Users authenticate to Kerberos by requesting a TGT (Ticket Granting Ticket). Once you grant a user a TGT, the user can use it to request service tickets from the KDC to be able to utilize other Kerberos based services. Kerberos uses the CBC (Cipher Block Chain) DES encryption protocol to encrypt all communications.

Note: You must already have a Kerberos environment established to use this method of authentication.

The Nessus implementation of Linux-based Kerberos authentication for SSH supports the aes-cbc and aes-ctr encryption algorithms. An overview of how Nessus interacts with Kerberos is as follows:

  • End user gives the IP of the KDC
  • nessusd asks sshd if it supports Kerberos authentication
  • sshd says yes
  • nessusd requests a Kerberos TGT, along with login and password
  • Kerberos sends a ticket back to nessusd
  • nessusd gives the ticket to sshd
  • nessusd is logged in

In both Windows and SSH credentials settings, you can specify credentials using Kerberos keys from a remote system. There are differences in the configurations for Windows and SSH.

Option Description

Username

The target system’s username.

Password

Password of the username specified.

Key Distribution Center (KDC)

This host supplies the session tickets for the user.

KDC Port

You can set this option to direct Nessus to connect to the KDC if it is running on a port other than 88.

KDC Transport

The KDC uses TCP by default in Linux implementations. For UDP, change this option. If you need to change the KDC Transport value, you may also need to change the port as the KDC UDP uses either port 88 or 750 by default, depending on the implementation.

Realm

The Realm is the authentication domain, usually noted as the domain name of the target (for example, example.com).

Elevate privileges with

Allows for increasing privileges once authenticated.

If Kerberos is used, you must configure sshd with Kerberos support to verify the ticket with the KDC. You must configure reverse DNS lookups properly for this to work. The Kerberos interaction method must be gssapi-with-mic.

Option Description

Username

The target system’s username.

Password

Password of the username specified.

Elevate privileges with

Allows for increasing privileges once authenticated.
Custom password prompt The password prompt used by the target host. Only use this setting when an interactive SSH session fails due to Tenable.io receiving an unrecognized password prompt on the target host's interactive SSH shell.
Option Default Value

Username(required)

The username that is used to authenticate via ssh to the system.

Domain

Set the domain the username is part of if using Windows credentials.

Thycotic Secret Name (required)

This is the value to store the secret as on the Thycotic server. It is referred to as the “Secret Name” on the Thycotic server.

Thycotic Secret Server URL (required)

Use this option to set the transfer method, target, and target directory for the scanner. You can find this value in Admin > Configuration > Application Settings > Secret Server URL on the Thycotic server. For example consider the following address https://pw.mydomain.com/SecretServer/. We parse this to know that HTTPS defines it is a ssl connection, pw.mydomain.com is the target address, /SecretServer/ is the root directory.

Thycotic Login Name (required)

The username to authenticate to the Thycotic server.

Thycotic Password (required)

The password associated with the Thycotic Login Name.

Thycotic Organization (required)

Use this value in cloud instances of Thycotic to define which organization your query should hit.

Thycotic Domain (optional)

This is an optional value set if you set the domain value for the Thycotic server.

Private Key (optional)

Use key based authentication for SSH connections instead of password.

Verify SSL Certificate

Verify if the SSL Certificate on the server is signed by a trusted CA.
Thycotic elevate privileges with The privilege escalation method you want to use to increase the user's privileges after initial authentication. Nessus supports multiple options for privilege escalation, including su, su+sudo and sudo. Your selection determines the specific options you must configure.
Option Default Value

Username

(Required) The username to log in to the hosts you want to scan.

BeyondTrust host

(Required) The BeyondTrust IP address or DNS address.

BeyondTrust port

(Required) The port BeyondTrust is listening on.

BeyondTrust API key

(Required) The API key provided by BeyondTrust.

Checkout duration

(Required) The length of time, in minutes, that you want to keep credentials checked out in BeyondTrust. Configure the Checkout duration to exceed the typical duration of your Nessus scans. If a password from a previous scan is still checked out when a new scan begins, the new scan fails.

Note: Configure the password change interval in BeyondTrust so that password changes do not disrupt your Nessus scans. If BeyondTrust changes a password during a scan, the scan fails.

Use SSL

If enabled, Nessus uses SSL through IIS for secure communications. You must configure SSL through IIS in BeyondTrust before enabling this option.

Verify SSL certificate

If enabled, Nessus validates the SSL certificate. You must configure SSL through IIS in BeyondTrust before enabling this option.

Use private key

If enabled, Nessus uses private key-based authentication for SSH connections instead of password authentication. If it fails, Nessus requests the password.

Use privilege escalation

If enabled, BeyondTrust uses the configured privilege escalation command. If it returns something, it uses it for the scan.
Option Description Required
Username The target system’s username.

yes
Lieberman host

The Lieberman IP/DNS address.

Note: If your Lieberman installation is in a subdirectory, you must include the subdirectory path. For example, type IP address or hostname / subdirectory path.

yes
Lieberman port The port on which Lieberman listens.

yes
Lieberman API URL The URL Nessus uses to access Lieberman. no
Lieberman user The Lieberman explicit user for authenticating to the Lieberman RED API.

yes
Lieberman password The password for the Lieberman explicit user.

yes
Lieberman Authenticator

The alias used for the authenticator in Lieberman. The name should match the name used in Lieberman.

Note: If you use this option, append a domain to the Lieberman user option, i.e., domain\user.

 no
Lieberman Client Certificate

The file that contains the PEM certificate used to communicate with the Lieberman host.

Note: If you use this option, you do not have to enter information in the Lieberman user, Lieberman password, and Lieberman Authenticator fields.

 no
Lieberman Client Certificate Private Key The file that contains the PEM private key for the client certificate. no
Lieberman Client Certificate Private Key Passphrase The passphrase for the private key, if required. no
Use SSL

If Lieberman is configured to support SSL through IIS, check for secure communication.

no
Verify SSL Certificate

If Lieberman is configured to support SSL through IIS and you want to validate the certificate, check this option. Refer to Custom CA documentation for how to use self-signed certificates.

no
System Name In the rare case your organization uses one default Lieberman entry for all managed systems, enter the default entry name.

no
Custom password prompt The password prompt used by the target host. Only use this setting when an interactive SSH session fails due to Nessus receiving an unrecognized password prompt on the target host's interactive SSH shell.

no
Option Default Value

Arcon host

(Required) The Arcon IP address or DNS address.

Note: If your Arcon installation is in a subdirectory, you must include the subdirectory path. For example, type IP address or hostname/subdirectory path.

Arcon port

The port on which Arcon listens.
API User

(Required) The API user provided by Arcon.
API Key

(Required) The API key provided by Arcon.
Authentication URL The URL Nessus Manager uses to access Arcon.

Password Engine URL

The URL Nessus Manager uses to access the passwords in Arcon.
Username (Required) The username to log in to the hosts you want to scan.
Checkout Duration

(Required) The length of time, in hours, that you want to keep credentials checked out in Arcon.

Configure the Checkout Duration to exceed the typical duration of your Tenable.io scans. If a password from a previous scan is still checked out when a new scan begins, the new scan fails.

Note: Configure the password change interval in Arcon so that password changes do not disrupt your Tenable.io scans. If Arcon changes a password during a scan, the scan fails.
Use SSL When enabled, Nessus Manager uses SSL through IIS for secure communications. You must configure SSL through IIS in Arcon before enabling this option.
Verify SSL When enabled, Nessus Manager validates the SSL certificate. You must configure SSL through IIS in Arcon before enabling this option.
Option Default Value

Centrify Host

(Required) The Centrify IP address or DNS address.

Note: If your Centrify installation is in a subdirectory, you must include the subdirectory path. For example, type IP address or hostname/subdirectory path.

Centrify Port

 The port on which Centrify listens.
API User (Required) The API user provided by Centrify

API Key

 (Required) The API key provided by Centrify.
Tenant The name of a specified team in a multi-team environment.

Authentication URL

 The URL Nessus Manager uses to access Centrify.
Password Engine URL The name of a specified team in a multi-team environment.
Username (Required) The username to log in to the hosts you want to scan.
Checkout Duration

The length of time, in minutes, that you want to keep credentials checked out in Centrify.

Configure the Checkout Duration to exceed the typical duration of your Nessus Manager scans. If a password from a previous scan is still checked out when a new scan begins, the new scan fails.

Note: Configure the password change interval in Centrify so that password changes do not disrupt your Nessus Manager scans. If Centrify changes a password during a scan, the scan fails.
Use SSL When enabled, Nessus Manager uses SSL through IIS for secure communications. You must configure SSL through IIS in Centrify before enabling this option.
Verify SSL When enabled, Nessus Manager validates the SSL certificate. You must configure SSL through IIS in Centrify before enabling this option.