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: ]](images/note.gif) |
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 Step 5. |
|
|
If you enable client public-key authentication, the following events occur when a client tries to access the switch using SSH:
-
The client sends its public key to the switch with a request for authentication.
-
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 tftpcommand to download this file to flash. -
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.
-
If there is a match, the switch:
-
Generates a random sequence of bytes.
-
Uses the client's public key to encrypt this sequence.
-
Send these encrypted bytes to the client.
-
-
The client uses its private key to decrypt the byte sequence.
-
-
Combines the decrypted byte sequence with specific session data.
-
Uses a secure hash algorithm to create a hash version of this information.
-
Returns the hash version to the switch.
-
-
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.
-
Generate a public/private key pair for each client you want to have SSH access to the switch. This can be a separate key for each client or the same key copied to several clients.
-
Copy the public key for each client into a client public-key text file.
-
Use
copy tftpto copy the client public-key file into the switch. Note that the switch can hold 100 keys. The new key is appended to the client public-key file
Use the aaa authentication ssh command to enable client public-key authentication.
These steps describe how to copy client public keys into the switch for challenge-response authentication, and require an understanding of how to use your SSH client application.
|
|
|
|
|
NOTE: Comments in public-key files may appear in a SSH client application's generated public key. While such comments may help to distinguish one key from another, they do not pose any restriction on the use of a key by multiple clients and/or users. Public key illustrations such as the key shown in A client public key usually include line breaks as a method for showing the whole key. However, in practice, line breaks in a public key will cause errors resulting in authentication failure. |
|
|
-
Use your SSH client application to create a public/private key pair, and see the documentation provided with your SSH client application for details. The switch supports the following client public-key properties:
Property Supported value Comments Key format ASCII
See Example of a correctly formatted public key. The key must be one unbroken ASCII string. If you add more than one client public key to a file, terminate each key (except the last one) with a <CR><LF>. Spaces are allowed within the key to delimit the key's components. Note that, unlike the use of the switch public key in an SSH client application, the format of a client public key used by the switch does not include the client's IP address.
Key type RSA or DSA
You can choose either RSA or DSA key types when using the
crypto key generate sshcommand. Thecertandautorunparameters only use RSA key types.Maximum supported public-key length 3072 bits
Shorter key lengths allow faster operation, but also mean diminished security.
Maximum host key sizes in bits RSA:
1024, 2048, 3072
DSA:
1024
Includes the bit size, public index, modulus, any comments,<CR>, <LF>, and all blank spaces.
If necessary, you can use an editor application to verify the size of a key. For example, placing a client public key into a Word for Windows text file and clicking on
File|Properties|Statisticslets you view the number of characters in the file, including spaces. -
Copy the client's public key into a text file (
filename.txt). For example, use the Notepad editor included with the Microsoft® Windows® software. If you want several clients to use client public-key authentication, copy a public key for each of these clients (10) into the file. Each key should be separated from the preceding key by a <CR><LF>. -
Copy the client public-key file into a TFTP server accessible to the switch.
Copying a client public key into the switch requires the following:
-
One or more client-generated public keys. See the documentation provided with your SSH client application.
-
A copy of each client public key stored in a single text file or individually on a TFTP server to which the switch has access. Terminate all client public keys in the file except the last one with a <CR><LF>.
-
|
|
|
|
|
NOTE: The actual content of a public-key entry in a public-key file is determined by the SSH client application generating the key. Although you can manually add or edit any comments the client application adds to the end of the key. |
|
|
Syntax:
Copies a public-key file from a TFTP server into flash memory in the switch.
The
appendoption adds the keys for operator access.The
manageroption replaces the keys for manager access; follow with the 'append' option to add the keys.The
operatoroption replaces the keys for operator access (default); follow with the 'append' option to add the keys.
Displays the clientpublic keys in the switch current client public-key file.
See SSH client public-key authentication for information about public keys saved in a configuration file.
The
babbleoption converts the key data to phonetic hashes that are easier for visual comparisons.The
fingerprintoption converts the key data to hexadecimal hashes that are for the same purpose.The
keylist-strselects keys to display (comma-delimited list).The
manageroption allows you to select manager public keysThe
operatoroption allows you to select operator public keys.
Example:
To copy a client public-key file named clientkeys.txt from a TFTP server at 10.38.252.195 and then display the file contents:
The client public-key file remains in the switch flash memory even if you erase the startup-config file, reset the switch, or reboot the switch.
Remove the existing client public-key file or specific keys by executing the clear crypto public-key command. This clears the public keys from both management modules. The module that is not active must be in standby mode.
Syntax:
Syntax:
After you TFTP a client public-key file into the switch, configure the switch to allow the following:
If an SSH client's public key matches the switch client public-key file, allow that client access to the switch. If there is not a public-key match, then deny access to that client.
![[CAUTION: ]](images/caution.gif)