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.

You must configure SSH on your device in FIPS mode to ensure 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 Collaborative Protection Profile for Network Devices (NDcPP).

  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, deactivate and commit the SSH configuration:

To disable the Netconf service, deactivate and commit the Netconf configuration:

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

Manage Remote User Login

An administrator might log in 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 Login Attempts

If the administrator provides an invalid authentication credentials, the device allows the administrator to reenter the credentials after an interval. The interval starts from 1 second after the first login attempt and increases exponentially after each attempt. If the number of authentication attempts exceed 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 reenter the credentials when the lockout period expires.

Configure Lockout Period

You can configure the duration for which the device gets locked after the administrator exceeds the limit for authentication attempts . The lockout period must be greater than zero. The configurable range for the lockout period is 1 through 43,200 minutes.

Configure Login 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 Login Attempts

You can configure a delay, in seconds, before a user can reenter a password after a failed attempt. The range is 1 through 3 seconds, 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 seconds, 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 duration, 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 seconds, with a default value of 5 seconds.

Configure SSH Root Login Denial

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

SSHv2 Protocol Security

The SSHv2 protocol provides secure terminal sessions with secure encryption. The SSHv2 protocol enforces the task of running the key-exchange phase and changing the encryption and integrity keys for a session. The system performs key exchange periodically, after specified seconds or after specified bytes of data have passed over a 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.

The time limit before renegotiation of session keys is 1 through 1440 minutes.

The data limit beyond which renegotiation happens for session keys is 51,200 through 4,294,967,295 byte.

Note:

If the SSH connection breaks, you must reinitiate the SSH connection to log back into the device.