Detections
Analytics

6.10.1.13 Ensure SSH Key Authentication is Disabled

Warning! Audit Deprecated

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

View Next Audit Version

Information

SSH Key based Authentication should be disabled (if not used for automation)

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.
Due to these limitations, it is recommended that SSH Key based Authentication be disabled when it is not required to support automation systems.
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, then this recommendation should not be implemented as it disables all use of SSH Key based Authentication.
When using SSH Keys for automation, 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. Consider using a Centralized SSH Key Management solution when trying to achieve this at scale.

Solution

To disable the use of SSH Key based Authentication, issue the following command from the [edit system service ssh] hierarchy:
[edit system services ssh]
user@host# set no-public-keys

Impact:
Ensure that SSH Key based Authentication is not required for automation systems and that any User Logins previously using SSH Keys have been configured with an alternative authentication methods before disabling SSH Key based Authentication.

Default Value:
SSH Key based authentication is supported, but no keys are configured by default.

See Also

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

Item Details

Category: CONFIGURATION MANAGEMENT

References: 800-53|CM-7, CSCv7|16.3

Plugin: Juniper

Control ID: 53aa29e26d09e357a94f3df04673b45bc9672972c8bd6392fa3097d921896631