Foundry Networks Switch and Router Installation And Configuration Manual page 117

Configuring RSA Challenge-Response Authentication
With RSA challenge-response authentication, a collection of clients' public keys are stored on the Foundry device.
Clients are authenticated using these stored public keys. Only clients that have a private key that corresponds to
one of the stored public keys can gain access to the device using SSH.
When RSA challenge-response authentication is enabled, the following events occur when a client attempts to
gain access to the device using SSH:
1. The client sends its public key to the Foundry device.
2. The Foundry device compares the client's public key to those stored in memory.
3. If there is a match, the Foundry device uses the public key to encrypt a random sequence of bytes.
4. The Foundry device sends these encrypted bytes to the client.
5. The client uses its private key to decrypt the bytes.
6. The client sends the decrypted bytes back to the Foundry device.
7. The Foundry device compares the decrypted bytes to the original bytes it sent to the client. If the two sets of
bytes match, it means that the client's private key corresponds to an authorized public key, and the client is
authenticated.
Setting up RSA challenge-response authentication consists of the following steps:
1. Importing authorized public keys into the Foundry device.
2. Enabling RSA challenge response authentication
Importing Authorized Public Keys into the Foundry Device
SSH clients that support RSA authentication normally provide a utility to generate an RSA 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. You should collect one public key from each client to be granted access to the Foundry device and
place all of these keys into one file. This public key file is imported into the Foundry device.
The following is an example of a public key file containing two public keys:
1024 65537 162566050678380006149460550286514061230306797782065166110686648548574
94957339232259963157379681924847634614532742178652767231995746941441604714682680
00644536790333304202912490569077182886541839656556769025432881477252978135927821
67540629478392662275128774861815448523997023618173312328476660721888873946758201
user@csp_client
1024 35 152676199889856769693556155614587291553826312328095300428421494164360924
76207475545234679268443233762295312979418833525975695775705101805212541008074877
26586119857422702897004112168852145074087969840642408451742714558592361693705908
74837875599405503479603024287131312793895007927438074972787423695977635251943 ro
ot@unix_machine
You can import the authorized public keys into the active configuration by loading them from a file on a TFTP
server or from a file on the Management IV module's PCMCIA flash card. Once the authorized public keys are
loaded, you can optionally save them to the startup-config file. If you import a public key file from a TFTP server or
PCMCIA flash card, the file is automatically loaded into the active configuration the next time the device is booted.
To load the public key file onto the Management IV module's PCMCIA flash card, you can copy it from a TFTP
server or from a Secure Copy (SCP)-enabled client.
For example, to copy a public key file called pkeys.txt from a TFTP server to a PCMCIA flash card in slot 1:
BigIron# copy tftp slot1 192.168.1.234 pkeys.txt
Syntax: copy tftp slot1 | slot2 <tftp-server-ip-addr> <from-name> [<to-name>]
December 2000
Configuring Secure Shell
4 - 3