Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configure SSH in FIPS Mode

Learn to configure SSH in FIPS mode on your device to enable secure remote management.

Configuring SSH on your device in FIPS mode is essential for ensuring compliance with stringent security requirements. You can remotely log in to your device in FIPS mode using SSH.

Configure SSH on Your Device in FIPS Mode

You need to configure the following cryptographic algorithms on your device to validate SSH support for NDcPPv2.2e.

  1. Specify the permissible SSH host-key algorithms for the system services.

  2. Specify the SSH key-exchange for Diffie-Hellman keys for the system services.

  3. Specify all the permissible message authentication code algorithms for SSHv2.

  4. Specify the ciphers allowed for SSHv2.

  5. Commit the changes:

To disable the SSH service, you can deactivate and commit the SSH configurations:

To disable the Netconf service, you can deactivate and commit the Netconf configurations:

See Supported Cryptographic Algorithms and Protocols for the details of cryptographic algorithms supported on your device.

Manage Remote User Login

An administrator might login remotely to a device through SSH. The device locally stores the administrator credentials and provides access to the remote administrator if the system receives a valid username and password.

Invalid Authentication Attempts

If the administrator provides an invalid authentication credential, the device allows the administrator to retry the authentication after an interval that starts after 1 second and increases exponentially. If the number of authentication attempts exceeded the configured limit, the device does not accept the further authentication attempts for a configured lockout period. During this lockout period the administrator can still have access to the device through the console as the root user. The administrator can retry the authentication when the lockout period expires.

Configure Lockout Period

You can configure the amount of time the device gets locked after exceeding the maximum failed authentication attempts. The lockout period must be greater than zero. The configurable range for the lockout period is 1 through 43,200 minutes.

Configure Authentication Attempt Limit

You can configure the number of failed login attempts that an administrator can perform. The failed login attempts range is 1 through 10, with a default value of 10.

Configure Delay After Failed Authentication Attempts

You can configure a delay, in seconds, before a user can try to enter a password after a failed attempt. The range is 1 through 3, with a default value of 2 seconds.

Here, backoff-threshold is the threshold for the number of failed login attempts before the user experiences a delay in being able to enter a password again. The range is 1 through 3, with a default value of 2 seconds.

Use the backoff-factor option to specify the length of the delay in seconds:

Here, backoff-factor is the length of time, in seconds, before a user can attempt to log in after a failed attempt. The delay increases by the value specified for each subsequent attempt after the threshold. The range is 5 through 10, with a default value of 5 seconds.

Configure SSH Root Login Denial

You can control the user access through SSH. Configure ssh root-login deny option to ensure the root account remains active and continues to have local administrative privileges to the device even if other remote users are logged off.

SSH2 Protocol Security

The SSH2 protocol provides secure terminal sessions utilizing secure encryption. The SSH2 protocol enforces running the key-exchange phase and changing the encryption and integrity keys for the session. The system performs the key exchange periodically, after specified seconds or after specified bytes of data have passed over the connection. You can configure thresholds for SSH rekeying. The TSF ensures SSH connections use the same session keys for no longer than one hour. It also limits the session keys to 1 GB of transmitted data. The rekey must happen when either of the thresholds reaches its limit.

Time limit before renegotiating session keys is 1 through 1440 minutes.

Data limit before renegotiating session keys is 51200 through 4294967295 byte.

Note:

If the SSH connection breaks unintentionally, you must re-initiate the SSH connection to log back into the device.