Detections
Analytics

1.1.3 Configure AAA Authentication - Local SSH keys

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

Using the client's public key to authenticate their SSH sessions circumvents the need for using passwords for an administrative login to the switch.

Rationale:

This is primarily an ease-of-use feature. It means that the administrators don't need to remember or key in passwords. It also can be used to significantly improve the security of any scripts or API calls that might use SSH.

Impact:

There are pros and cons to this approach.

Pro:

Scripts and API calls that use SSH no longer need to have credentials embedded in them. While this can be done securely (using password vaults for instance), all to often the credentials are in clear-text, in the code or in an input file.

This is popular with network administrators, as they no longer need to key in passwords, or 'grab' their password from a password manager application.

It means that administrators can no longer configure easy to guess passwords.

Con:

The private half of the PKI exchange (client side) can be available if the administrator's workstation or account is compromised

An inventory of SSH hosts that use key based authentication needs to be maintained if this approach is used. This is so that if a key needs to be replaced or deleted, the list of hosts that need to be updated is easily accessed. This can be time sensitive if an administrator has left the organization, or if a laptop is lost or stolen. Even if this is just due to regular hardware replacement or a policy that expires keys at regular intervals, missing a device can be a 'time bomb' that is often not found until the worst possible moment

Normally the best recommendation is to use a back-end authentication source (such as AD), with RADIUS or TACACS+ as the authentication protocol. The back end directory can then enforce whatever complexity or password change requirements are needed. In particular if an administrator leaves the organization or changes departments, those situations can be managed by changing AD Group membership or by disabling the account in question.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

Create the client's SSH public and private keys. The keys must be in OpenSSH format for the NX-OS switch to interpret them correctly. Use either RSA or DSA algorithms, and be sure to specify enough bits for entropy (2048 minimum, more is of course better)

Upload the client's SSH public key, and store it on the bootflash of the switch.

Be sure that the file has a meaningful name, often the users's initials and the key algorithm (RSA or DSA) is in the filename. This makes it easier to remove or replace that file as keys are expired out, workstations migrate or administrators leave the organization.

To enable key-based authentication for one local user (for instance, Davey Jones), enter the command:

switch(config)# username djadmin sshkey file bootflash:dj_rsa.pub

Alternatively, the ssh key can be defined in the username configuration line:

switch(config)# username djadmin sshkey ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAy19oF6QaZl9G+3f1XswK3OiW4H7YyUyuA50rv7gsEPjhOBYmsi6PAVKui1nIf/DQhum+lJNqJP/eLowb7ubO+lVKRXFY/G+lJNIQW3g9igG30c6k6+XVn+NjnI1B7ihvpVh7dLddMOXwOnXHYshXmSiH3UD/vKyziEh5S4Tplx8=

The file based method is usually preferred, as they keys can be changed without modifying the configuration of the switch. Also, the keys are not stored in any archived copy of the configuration.
Note that the username and file name will vary depending on your organization's policies, procedures and standards

Default Value:

SSH keys are not created or defined by default.

See Also

https://workbench.cisecurity.org/files/3102

Item Details

Plugin: Cisco

Control ID: 272a1b142cc96517d560b659fffc8ec2b358ece40d8847112fcbe471e0d27d61