Configuring Secure Shell (SSH)
Further Information on SSH Client Public-Key Authentication
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 ten RSA or DSA public keys for authenticating clients. This requires storing an ASCII version of each client’s public key (without babble conversion, or fingerprint conversion) in
aclient public-key file that you create and TFTP-copy to the switch. In this case, only clients that have a private key corresponding to one of the stored public keys can gain access to the switch using SSH. That is, 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, then 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 that even 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. Refer to “5. Configure the Switch for SSH Authentication” on page 6-18.)
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 authenti- cation.
2.The switch compares the client’s public key to those stored in the switch’s client-public-key file. (As a prerequisite, you must use the switch’s copy tftp command to download this file to flash.)
3.If there is not a match, and you have not configured the switch to accept
alogin password as a secondary authentication method, the switch denies SSH access to the client.
4.If there is a match, the switch:
a.Generates a random sequence of bytes.
b.Uses the client’s public key to encrypt this sequence.
c.Send these encrypted bytes to the client.
5.The client uses its private key to decrypt the byte sequence.
6.The client then:
