Enable SSH Local Security Checks

Before You Begin

This section applies to Linux and Network Devices

This section is intended to provide a high-level procedure for enabling SSH between the systems involved in the Nessus credentialed checks. It is not intended to be an in-depth tutorial on SSH. It is assumed the reader has the prerequisite knowledge of Linux system commands.

Generate SSH Public and Private Keys

The first step is to generate a private/public key pair for the Nessus scanner to use.

This key pair can be generated from any of your Linux systems, using any user account. However, it is important that the keys be owned by the defined Nessus user.

To generate the key pair, use ssh-keygen and save the key in a safe place. In the following example the keys are generated on a Red Hat ES 3 installation.

# ssh-keygen -t dsa

Generating public/private dsa key pair.

Enter file in which to save the key (/Users/test/.ssh/id_dsa): /home/test/Nessus/ssh_key

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in

/home/test/Nessus/ssh_key.

Your public key has been saved in

/home/test/Nessus/ssh_key.pub.

The key fingerprint is:

06:4a:fd:76:ee:0f:d4:e6:4b:74:84:9a:99:e6:12:ea

#

Do not transfer the private key to any system other than the one running the Nessus server. When ssh-keygen asks you for a passphrase, enter a strong passphrase or hit the Return key twice (i.e., do not set any passphrase). If a passphrase is specified, it must be specified in the Policies → Credentials → SSH settings options in order for Nessus to use key-based authentication.

Nessus Windows users may wish to copy both keys to the main Nessus application directory on the system running Nessus (C:\Program Files\Tenable\Nessus by default), and then copy the public key to the target systems as needed. This makes it easier to manage the public and private key files.

Create a User Account and Setting up the SSH Key

On every target system to be scanned using local security checks, create a new user account dedicated to Nessus. This user account must have exactly the same name on all systems. For this document, we will call the user nessus, but you can use any name.

Once the account is created for the user, make sure that the account has no valid password set. On Linux systems, new user accounts are locked by default, unless an initial password was explicitly set. If you are using an account where a password had been set, use the passwd –l command to lock the account.

You must also create the directory under this new account’s home directory to hold the public key. For this exercise, the directory will be /home/nessus/.ssh. An example for Linux systems is provided below:

# passwd –l nessus

# cd /home/nessus

# mkdir .ssh

#

For Solaris 10 systems, Sun has enhanced the passwd(1) command to distinguish between locked and non-login accounts. This is to ensure that a user account that has been locked may not be used to execute commands (e.g., cron jobs). Non-login accounts are used only to execute commands and do not support an interactive login session. These accounts have the NP token in the password field of /etc/shadow. To set a non-login account and create the SSH public key directory in Solaris 10, run the following commands:

# passwd –N nessus

# grep nessus /etc/shadow

nessus:NP:13579::::::

# cd /export/home/nessus

# mkdir .ssh`

#

Now that the user account is created, you must transfer the key to the system, place it in the appropriate directory and set the correct permissions.

From the system containing the keys, secure copy the public key to system that will be scanned for host checks as shown below. 192.1.1.44 is an example remote system that will be tested with the host-based checks.

# scp ssh_key.pub root@192.1.1.44:/home/nessus/.ssh/authorized_keys

#

You can also copy the file from the system on which Nessus is installed using the secure FTP command, sftp. Note that the file on the target system must be named authorized_keys.

Note: Do not use the no-pty option in your authorized_keys file for SSH authentication. This can impact the SSH credentialed scans.

Return to the System Housing the Public Key

Set the permissions on both the /home/nessus/.ssh directory, as well as the authorized_keys file.

# chown -R nessus:nessus ~nessus/.ssh/

# chmod 0600 ~nessus/.ssh/authorized_keys

# chmod 0700 ~nessus/.ssh/`

#

Repeat this process on all systems that will be tested for SSH checks (starting at Creating a User Account and Setting up the SSH Key above).

Test to make sure that the accounts and networks are configured correctly. Using the simple Linux command id, from the Nessus scanner, run the following command:

# ssh -i /home/test/nessus/ssh_key nessus@192.1.1.44 id

uid=252(nessus) gid=250(tns) groups=250(tns)

#

If it successfully returns information about the nessus user, the key exchange was successful.

Enable SSH Local Security Checks on Network Devices

In addition to using SSH for local security checks, Nessus also supports local security checks on various network devices. Those network devices currently include Cisco IOS devices, F5 networks devices, Huawei devices, Junos devices, and Palo Alto Networks devices.

Network devices that support SSH require both a username and password. Currently, Nessus does not support any other forms of authentication to network devices.