Filter
Top Products
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 a client
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. Configuring 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
a login 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:
6-22