Detections
Analytics

6.6.13 Ensure SSH Key Authentication is not set for User Logins

Information

SSH Key Based Authentication should not be used for User Logins

Rationale:

Due to the sensitive nature of SSH, potentially allowing full management of the targeted device, protecting SSH access using strong authentication methods is essential to the security of the device.

One method which is supported in SSH for stronger authentication is the use of Public/Private Encryption Key Pairs in place of a more traditional login prompt for a Username and Password. Instead, an administrator uploads the user's Public key to the JUNOS (or other) device to be managed.

When the user connects, they will use their Private key to encrypt some session specific data. The JUNOS device can verify the Users identity by decrypting that data using the Public key configured previously and comparing it to an expected result. If the results match, then the user must have access to the Private key, so is considered valid.

Unfortunately using SSH Keys to authenticate User Logins to JUNOS devices introduce a number of security issues:

Public Keys may only be configured locally on each JUNOS device

Public Keys are used instead of centralized AAA using TACACS+ or RADIUS as covered in Recommendation 6.8.1 Ensure External AAA Server is set

The use of SSH Keys means only a single Authentication Factor (the keys) can be used, preventing the use of Multi Factor Authentication as covered in 6.6.14 Ensure Multi-Factor is used with External AAA

JUNOS does not provide any method to automate rollover or locking of keys. If keys are compromised/lost, they must be changed on every JUNOS device on which they are configured.

Some SSH implementation support the use of X.509 PKI Certificates for managing SSH Keys, but JUNOS does not.

Because of these limitations and the difficulty in auditing and managing SSH Keys on JUNOS devices, this method should not be used for Authentication of User logins or for the Root User.

In some instances, such as when using PyEZ or NETCONF based automation over SSH, it may be preferable to authenticate a limited number of automation services using SSH Keys, rather than 'hard coding' user details into scripts. Where this is the case, it is imperative to have strong key management procedures in use to control and audit access to the Private Keys used and a process to allow for rollover and revocation of compromised keys.

Impact:

Careful configuration of permissions following the least privilege principle is essential for secure and reliable management of the network.

When configuring remote AAA, it is recommended that a local Emergency Access Account also be configured to allow management of the device in the event that AAA services are unavailable.

Solution

For each User Login configured with SSH Key based Authentication, you can delete the SSH Key with the following command from the [edit system login] hierarchy:

[edit system login]
user@host# delete user <User ID> authentication

The user can then be configured with a password locally or, inline with Recommendation 6.8.1 Ensure External AAA Server is set , leave the authentication method blank and allow the External AAA to control Authentication.
Alternatively, you may wish to delete the local user account entirely using the following command:

[edit system login]
user@host# delete user <User ID>

Default Value:

By default, JUNOS does not use SSH Key based Authentication

See Also

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

Item Details

Category: IDENTIFICATION AND AUTHENTICATION

References: 800-53|IA-2(1), CSCv7|11.5

Plugin: Juniper

Control ID: 81f2de165ee677da4924841cfc80d72f5439d194ce2bcbf1a9f414c059bbbb29