Common access card (two-factor) authentication


A common access card (CAC) is a United States Department of Defense (DoD) smart card for multifactor authentication. CACs are issued as standard identification for active-duty military personnel, reserve personnel, civilian employees, non-DoD government employees, state employees of the National Guard, and eligible contractor personnel. In addition to its use as an ID card, a CAC is required for access to government buildings and computer networks.

Two-factor authentication

Part of the requirement necessary to satisfy the Federal Government Certification is two-factor authentication. Two-factor authentication is the redundant authentication of the CAC. For example, the CAC satisfies two-factor authentication by mandating that you have both the physical card and know the pin number associated with the card.

To provide support for CAC authentication, the requirement for the network is the establishment of SSH connections. Two-factor authentication constitutes authentication based on public key or certificate and username/password on the switch.


The following are some of the restrictions when working with CAC authentication:

  • Support is not provided for any other management connections other than SSH.

  • Support is not provided for any switch acting as CAC SSH client.

  • Support is not provided for public-key authentication based on DSA and ECDSA public keys.

  • The maximum number of client public keys that can be installed is 10.

  • When there is failure in any one of the authentication methods, the SSH connection will not be established.

  • The following table lists the invalid authentication methods for SSH.



















Expected behaviors

With include-credentials command
  • When the command include-credentials is enabled, public keys are stored both in configuration and flash files.

  • When the command [no] include-credentials is executed, the client public key is stored only in the flash.

  • When the command [no] include-credentials store-in-config is executed, behavior is then based on the user entry made with the pop-up message.

    The command HP-switch(config)# [no] include-credentials store-in-config will display a message similar to:

    This will remove any switch passwords and inactive SSH 
    authorized keys from all configuration files.  This will also restore
     the functionality to store only a single set of passwords and authorized 
    keys on the switch.
    Continue (y/n)?  y
    The SSH authorized keys associated with the active configuration will be 
    Would you like to retain these as the switch global SSH authorized keys 
    (y/n)?  y
    If the above option entered is “y”, then the client public key will be 
    available in the flash but not in the config.
    If the above option entered is “n”, then the client public key is neither 
    available in the flash nor in the config.

When the zeroization command HP-Switch(config)# crypto key zeroize ssh-client-key is executed, the client public keys will be zeroized in the flash.

HP-2920-24G(config)# crypto key zeroize ssh-client-key

The manager key pair will be deleted, continue (y/n)? y 

The command erase all zeroize will also perform the 
zeroization of the key files in the flash.

The command erase all will only delete the key files from 
Switch is moved to/from enhanced security mode

Since the secure mode change goes through zeroization, the client keys are deleted and the switch will revert to the default configuration without any client keys on the switch.

Attempting to configure a two-factor authentication method with no public key or username configured

If, during the download of the configuration file, the username and/or public key is not configured, then no action will be taken. A warning message will display similar to:

username and/or public key is not configured.

An RMON will be logged with the message that the authentication method is set to two-factor with some configuration missing.

When the user tries to connect using SSH, the connection will fail.

Deletion of the public key and/or username when the authentication method is set to two-factor authentication

For the following three scenarios:

  • After the authentication method is set to two-factor, if the client public keys are deleted while the usernames still exists on the switch...

  • After the authentication method being set to two-factor, if the username is deleted the public key exists on the switch...

  • When both the public key and usernames are deleted while the authentication method is being set to two-factor authentication...

The new SSH connection will fail at either the public key authentication and/or username/password authentication. RMON will be logged with appropriate message on the switch.

[NOTE: ]

NOTE: An alternative solution is to block the deletion of the public key and/or username when the authentication method is set as two-factor authentication. With this approach, the impact of many configurations need to be taken care cautiously since the username/password can be configured through many interfaces such as SNMP, REST, WebUI, Menu, setup mgmt.-interfaces, and include-credentials.

Authentication method re-configured at run time

If the authentication method is reconfigured at run time, the modified authentication method will be applied when the new connection will be established.