Access Security Guide K/KA/KB.15.15

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:
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:
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.
b. Uses a secure hash algorithm to create a hash version of this information.
c. Returns the hash version to the switch.
7. The switch computes its own hash version of the data from step 6 (page 244) and compares it
to the client's hash version. If they match, the client is authenticated. Otherwise, the client is
denied access.
General operating rules and operating notes
• Public keys generated on an SSH client must be exportable to the switch. The switch can store
10 client key pairs.
• The switch own public/private key pair and the optional client public-key file are stored in
the switch flash memory and are not affected by reboots or the erase startup-config command.
• Once you generate a key pair on the switch you should avoid re-generating the key pair
without a compelling reason. Otherwise, you must re-introduce the switch public key on all
management stations (clients) you previously set up for SSH access to the switch. In some
situations this can temporarily allow security breaches.
• With SSH running, the switch allows one console session and up to five other sessions (SSH
and/or Telnet).
• There can be up to six sessions running SSH or Telnet concurrently. However, if stacking is
being used, each stacking connection reduces the number of sessions available, for example,
five connections into the stack leaves only one session available for SSH or Telnet.
• The SSH server may challenge the client to authenticate itself depending on the authentication
methods configured on the destination SSH server. The client first tries the "none" method of
authentication; if that is unsuccessful, it examines the list of supported authentication methods
from the server, if provided. If the server does not provide such a list, all methods of
authentication will be tried in the following order until the session is successfully opened or
rejected by the server:
• Authentication method "publickey", if a private key has been loaded onto the switch.
• Authentication method "password".
• During "public-key" authentication, the client must use its private key to authenticate itself to
the server. There can be only one key pair on the switch for the manager.
244 Secure Shell (SSH)