System Security Configuration Guide for Cisco 8000 Series Routers, IOS XR Releases

Public-key authentication to SSH servers

Updated: September 18, 2026

Want to summarize with AI?

Explains how a Cisco IOS XR router stores public keys and authenticates SSH clients that prove possession of the corresponding private keys.

Public-key authentication to an SSH server is a passwordless method that

associates imported public keys with a router user account
verifies a client signature with one of those keys, and
permits access only when the signature and username match.

From Cisco IOS XR Software Release 7.11.1, a router supports up to four public keys per user. A user can therefore connect from as many as four client systems without requiring a separate router username for each system.

Table 1. Feature History Table
Feature Name	Release Information	Feature Description
Multiple Public Keys per User for Public Key-based Authentication	Release 25.4.1	Introduced in this release on: Fixed Systems (8010 [ASIC: A100])(select variants only) This feature is supported on: 8011-32Y8L2H2FH 8011-12G12X4Y-A/D
Multiple Public Keys per User for Public Key-based Authentication	Release 25.1.1	Introduced in this release on: Fixed Systems (8700 [ASIC: K100], 8010 [ASIC: A100])(select variants only) This feature is supported on: 8712-MOD-M 8011-4G24Y4H-I
Multiple Public Keys per User for Public Key-based Authentication	Release 24.4.1	Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100])(select variants only); Modular Systems (8800 [LC ASIC: P100])(select variants only) *This feature is supported on: 8212-48FH-M 8711-32FH-M 88-LC1-36EH 88-LC1-12TH24FH-E 88-LC1-52Y8H-EM
Multiple Public Keys per User for Public Key-based Authentication	Release 7.11.1	We provide greater flexibility to access secure routers by allowing four public keys to be used for authentication. With the ability to associate multiple public keys with your user account on the router, we've also simplified the authentication process by eliminating the need to create unique users for each SSH client device. The feature introduces these changes: CLI: The second , third , and fourth keywords are introduced in the crypto key import authentication rsa command. The second , third , and fourth keywords are introduced in the crypto key zeroize authentication rsa command. The second , third , and fourth keywords are introduced in the keystring command.` YANG Data Models: `Cisco-IOS-XR-crypto-act` `Cisco-IOS-XR-um-ssh-cfg` (See GitHub, YANG Data Models Navigator)

Security characteristics

The private keys remain on their client systems. Signature verification is less exposed to brute-force password guessing and password theft than reusable password authentication.

How multiple public keys authenticate a user

Each SSH client generates its own key pair. The router stores the corresponding public key under a shared user account.

Summary

A client proves possession of its private key by signing authentication data. The router tests the signature with the public keys stored for that user.

Workflow

Figure 1. Multiple public keys per user for public key-based authentication

These stages describe authentication with multiple public keys:

Up to four client systems independently generate public-private key pairs.
An administrator imports or configures each public key, one at a time, under the same router username.
A client requests access for that username and presents a signature created with its private key.
The router compares the signature with the public keys associated with the username.
If one public key verifies the signature, the router authenticates the user. If none verifies it, the router denies access.

Result

The same router user can authenticate from any client that holds one of the corresponding private keys.

Guidelines for public-key authentication to SSH servers

Add and manage each public key in a supported format and operation mode.

Associate no more than four public keys with one user.
Import or configure only one public key at a time.
Use RSA, Base64, PEM PKCS#1, or PEM PKCS#8 when importing RSA public-key files.
Import RSA keys with crypto key import authentication rsa .
Import security keys with ssh-server authorized-keys . Include the complete security-key structure and application-data field; the router rejects malformed keys.
Delete a key in the same XR configuration or XR EXEC mode that was used to import it.

Key-count, format, structure, and mode mismatches can prevent import or later key removal.

Configure public-key authentication to a router

Allow one router user to authenticate from multiple SSH client systems without a password.

Use either public-key file import or direct SSH key configuration. Add the keys sequentially.

Before you begin

Generate the RSA key pair on each SSH client.
Copy each public-key file to the router when using the import method.

Procedure

Create the router user for public-key import.

Example:

Router# configure
Router(config)# username sample-user1
Router(config)# commit

Import as many as four client public-key files and commit the configuration.

Example:

Router# configure
Router(config)# crypto key import authentication rsa username sample-user1 disk0:/sample-key1.pub
Router(config)# crypto key import authentication rsa username sample-user1 second disk0:/sample-key2.pub
Router(config)# crypto key import authentication rsa username sample-user1 third disk0:/sample-key3.pub
Router(config)# crypto key import authentication rsa username sample-user1 fourth disk0:/sample-key4.pub
Router(config)# commit

You can reference a supported remote file path instead of copying the file to local storage.

Alternatively, configure public-key strings directly under an SSH server username.

Example:

Router# configure
Router(config)# ssh server username sample-user2
Router(config-user-key)# keystring ssh-rsa sample-public-key-1
Router(config-user-key)# keystring ssh-rsa second sample-public-key-2
Router(config-user-key)# keystring ssh-rsa third sample-public-key-3
Router(config-user-key)# keystring ssh-rsa fourth sample-public-key-4
Router(config-user-key)# commit

Replace each sample key value with the complete OpenSSH public-key string from the corresponding client.

Connect from a client with the shared username.
Example:
```
client-host$ ssh sample-user1@192.0.2.2
```
Verify imported keys and active public-key sessions.
Example:
```
Router# show crypto key authentication rsa sample-user1 all
Router# show ssh
```
The key output lists the configured key labels, and active SSH sessions report RSA public-key authentication.

The user can access the router from any client that holds a private key corresponding to one of the configured public keys.

Delete user public keys from a router

Revoke public-key access for all users, one user, or one client key.

Use the deletion method that matches the method and operation mode used to add the key.

Procedure

To revoke every imported RSA authentication key, delete all keys and commit the configuration.

Example:

Router# configure
Router(config)# crypto key zeroize authentication rsa all
Do you really want to remove all these keys? [yes/no]: yes
Router(config)# commit

To revoke every imported RSA key for one user, delete that user's keys and commit the configuration.

Example:

Router# configure
Router(config)# crypto key zeroize authentication rsa username sample-user all
Do you really want to remove all these keys? [yes/no]: yes
Router(config)# commit

To remove all directly configured SSH keys for one user, delete the SSH server username configuration.
Example:
```
Router# configure
Router(config)# no ssh server username sample-user
Router(config)# commit
```

To revoke only the third directly configured key, delete that key from the SSH username configuration.

Example:

Router# configure
Router(config)# no ssh server username sample-user keystring third
Router(config)# commit

The selected public keys no longer authorize SSH access to the router.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.