SSH client public-key authentication notes

When configured for SSH operation, the switch automatically attempts to use its own host public key to authenticate itself to SSH clients. To provide the optional, opposite service—client public-key authentication to the switch—you can configure the switch to store up to 10 public keys for authenticating clients. This requires storing an ASCII version of each client's public key (without babble conversion, or fingerprint conversion) in a client public-key file that you create and TFTP-copy to the switch. In this case, only clients with a private key corresponding to one of the stored public keys can gain access to the switch using SSH. If you use this feature, only the clients whose public keys are in the client public-key file you store on the switch will have SSH access to the switch over the network. If you do not allow secondary SSH login (operator) access via local password the switch will refuse other SSH clients.

SSH clients that support client public-key authentication normally provide a utility to generate a key pair. The private key is usually stored in a password-protected file on the local host; the public key is stored in another file and is not protected.

NOTE:

Without using client public-key authentication you can still require authentication from whoever attempts to access the switch from an SSH client— by employing the local username/password, TACACS+, or RADIUS features. See 5.

If you enable client public-key authentication, the following events occur when a client tries to access the switch using SSH:

  1. The client sends its public key to the switch with a request for authentication.

  2. The switch compares the client's public key to those stored in the switch client public-key file. As a prerequisite, use the switch copy tftp command to download this file to flash.

  3. If there is no match, and you have not configured the switch to accept a login password as a secondary authentication method, the switch denies SSH access to the client.

  4. If there is a match, the switch:

    1. Generates a random sequence of bytes.

    2. Uses the client's public key to encrypt this sequence.

    3. Send these encrypted bytes to the client.

  5. The client uses its private key to decrypt the byte sequence.

  6. The client then:

    1. Combines the decrypted byte sequence with specific session data.

    2. Uses a secure hash algorithm to create a hash version of this information.

    3. Returns the hash version to the switch.

  7. The switch computes its own hash version of the data from step 6 and compares it to the client's hash version. If they match, the client is authenticated. Otherwise, the client is denied access.