Detections
Analytics
6.10.1.13 Ensure SSH Key Authentication is Disabled
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.
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.
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
Default Value:
SSH Key based authentication is supported, but no keys are configured by default.
See Also
Item Details
Audit Name: CIS Juniper OS Benchmark v2.1.0 L2
Category: IDENTIFICATION AND AUTHENTICATION
References: 800-53|IA-2, 800-53|IA-2(1), CSCv7|11.5, CSCv7|16.2, CSCv7|16.3
Plugin: Juniper
Control ID: 01023966151c0d9e74869dc0c01195f428914a26977fa568860d5cab2812840a