Filter
Top Products
95
Enhancements in Release F.04.08
Configuring Secure Shell (SSH)
Further Information on SSH Client Public-Key Authentication
The section titled “5. Configuring the Switch for SSH Authentication” on page 92 lists the steps for
configuring SSH authentication on the switch. However, if you are new to SSH or need more details
on client public-key authentication, this section may be helpful.
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 authenticate up to ten SSH clients.
This requires storing an ASCII version of each client’s public key (without PEM encoding, 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 Authentica-
tion” on page 92.)
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’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:
a. Combines the decrypted byte sequence with specific session data.