SSH

On Linux systems and supported network devices, Nessus uses Secure Shell (SSH) protocol version 2 based programs (e.g., OpenSSH, Solaris SSH, etc.) for host-based checks.

This mechanism encrypts the data in transit to protect it from being viewed by sniffer programs. Nessus supports five types of authentication methods for use with SSH: username and password, public/private keys, digital certificates, and Kerberos.

Users can select SSH settings from the Credentials menu and enter credentials for scanning Linux systems.

These credentials are used to obtain local information from remote Linux systems for patch auditing or compliance checks.

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

Global Credential Settings

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 will only attempt to log into hosts in this file. This can ensure that the same username and password you are using to audit your known SSH servers is not used to attempt a log into a system that may not be under your control.
Preferred port	22	This option can be set 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 will impersonate while scanning.
Attempt least privilege (experimental)	Cleared	Enables or disables dynamic privilege escalation. When enabled, Nessus attempts to run the scan with an account with lesser privileges, even if the Elevate privileges with option is enabled. If a command fails, Nessus will escalate 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

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, the public key is used to encrypt data and the private key is used 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. Formats from other SSH applications, including PuTTY and SSH Communications Security, must be converted to 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 has been 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 only accept certain types of encryption. Check your SSH server to ensure the correct algorithm is supported.

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

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

If an account other than root must be used for privilege escalation, it can be specified 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 Open SSH key file of the user.
Private key passphrase	Passphrase of the Private Key.
Elevate privileges with	Allows for increasing privileges once authenticated.

Certificate

Option	Description
Username	Username of the account which is being used for authentication on the host system.
User Certificate	RSA or DSA Open SSH certificate file of the user.
Private Key	RSA or DSA Open SSH key file of the user.
Private key passphrase	Passphrase of the Private Key.
Elevate privileges with	Allows for increasing privileges once authenticated.

CyberArk (Nessus Manager only)

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
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 the CyberArk Central Credential Provider is configured to use basic authentication, you can fill in this field for authentication.
Central Credential Provider Password	If the CyberArk Central Credential Provider is configured 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 CyberArk Central Credential Provider is configured to support SSL through IIS check for secure communication.
Verify SSL Certificate	If CyberArk Central Credential Provider is configured to support SSL through IIS and you want to validate the certificate check this. 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

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 a user is granted a TGT, it can be used 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. Note that 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	This option can be set 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. Note that 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 (e.g., example.com).
Elevate privileges with	Allows for increasing privileges once authenticated.

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

Password

Option	Description
Username	The target system’s username.
Password	Password of the username specified.
Elevate privileges with	Allows for increasing privileges once authenticated.

Thycotic Secret Server Authentication

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 that the secret is stored as on the Thycotic server. It is referred to as the “Secret Name” on the Thycotic server.
Thycotic Secret Server URL (required)	This is used to set the transfer method, target , and target directory for the scanner. The value can be found in Admin > Configuration > Application Settings > Secret Server URL on the Thycotic server. For example consider the following address https://pw.mydomain.com/SecretServer/. We will 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)	This value is used in cloud instances of Thycotic to define which organization your query should hit.
Thycotic Domain (optional)	This is an optional value set if the domain value is set 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.

BeyondTrust

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, the password will be requested.
Use privilege escalation	If enabled, BeyondTrust uses the configured privilege escalation command. If it returns something, it will use it for the scan.

Lieberman

Option	Default Value
Username	(Required) The target system’s username.
Lieberman host	(Required) 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.
Lieberman port	(Required) The port on which Lieberman listens.
Lieberman user	(Required) The Lieberman explicit user for authenticating to the Lieberman RED API.
Lieberman password	(Required) The password for the Lieberman explicit user.
Use SSL	If Lieberman is configured to support SSL through IIS, check for secure communication.
Verify SSL certificate	If Lieberman is configured to support SSL through IIS and you want to validate the certificate, check this. Refer to custom_CA.inc documentation for how to use self-signed certificates.
System Name	In the rare case your organization uses one default Lieberman entry for all managed systems, enter the default entry name.

Copyright © 2019 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of Tenable, Inc.. Tenable.sc, Lumin, Assure, and the Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.