0% found this document useful (0 votes)
36 views12 pages

X.509v3 Certificates For SSH Authentication

The document outlines the configuration and usage of X.509v3 Certificates for SSH Authentication, which utilizes public key infrastructure (PKI) for authenticating servers and users via digital certificates issued by a Certificate Authority (CA). It details prerequisites, restrictions, and step-by-step procedures for setting up server and user certificate profiles, as well as verifying authentication. Additionally, it discusses the use of Online Certificate Status Protocol (OCSP) for certificate revocation checks in the context of SSH authentication.

Uploaded by

Kristian
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
36 views12 pages

X.509v3 Certificates For SSH Authentication

The document outlines the configuration and usage of X.509v3 Certificates for SSH Authentication, which utilizes public key infrastructure (PKI) for authenticating servers and users via digital certificates issued by a Certificate Authority (CA). It details prerequisites, restrictions, and step-by-step procedures for setting up server and user certificate profiles, as well as verifying authentication. Additionally, it discusses the use of Online Certificate Status Protocol (OCSP) for certificate revocation checks in the context of SSH authentication.

Uploaded by

Kristian
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

X.

509v3 Certificates for SSH Authentication


The X.509v3 Certificates for SSH Authentication feature uses public key algorithm (PKI) for server and user
authentication, and allows the Secure Shell (SSH) protocol to verify the identity of the owner of a key pair
via digital certificates, signed and issued by a Certificate Authority (CA).
This module describes how to configure server and user certificate profiles for a digital certificate.
• Prerequisites for X.509v3 Certificates for SSH Authentication, on page 1
• Restrictions for X.509v3 Certificates for SSH Authentication, on page 1
• Information About X.509v3 Certificates for SSH Authentication, on page 2
• How to Configure X.509v3 Certificates for SSH Authentication, on page 3
• Verifying the Server and User Authentication Using Digital Certificates , on page 6
• Configuration Examples for X.509v3 Certificates for SSH Authentication, on page 10
• Additional References for X.509v3 Certificates for SSH Authentication, on page 11
• Feature History for X.509v3 Certificates for SSH Authentication, on page 11

Prerequisites for X.509v3 Certificates for SSH Authentication


The X.509v3 Certificates for SSH Authentication feature replaces the ip ssh server authenticate user
command with the ip ssh server algorithm authentication command. Configure the default ip ssh server
authenticate user command to remove the ip ssh server authenticate user command from the configuration.
The IOS secure shell (SSH) server will start using the ip ssh server algorithm authentication command.
When you configure the ip ssh server authenticate user command, the following message is displayed:

Warning SSH command accepted; but this CLI will be deprecated soon. Please move to new CLI ip ssh server
algorithm authentication. Please configure the default ip ssh server authenticate user to make the CLI
ineffective.

Restrictions for X.509v3 Certificates for SSH Authentication


• The X.509v3 Certificates for SSH Authentication feature implementation is applicable only on the Cisco
IOS Secure Shell (SSH) server side.

X.509v3 Certificates for SSH Authentication


1
X.509v3 Certificates for SSH Authentication
Information About X.509v3 Certificates for SSH Authentication

• The Cisco IOS SSH server supports only the x509v3-ssh-rsa algorithm-based certificate for server and
user authentication.

Information About X.509v3 Certificates for SSH Authentication


X.509v3 Certificates for SSH Authentication Overview
The Secure Shell (SSH) protocol provides a secure remote access connection to network devices. The
communication between the client and server is encrypted.
There are two SSH protocols that use public key cryptography for authentication. The Transport Layer Protocol,
uses a digital signature algorithm (called the public key algorithm) to authenticate the server to the client. And
the User Authentication Protocol uses a digital signature to authenticate (public key authentication) the client
to the server.
The validity of the authentication depends upon the strength of the linkage between the public signing key
and the identity of the signer. Digital certificates, such as those in X.509 Version 3 (X.509v3), are used to
provide identity management. X.509v3 uses a chain of signatures by a trusted root certification authority and
intermediate certificate authorities to bind a public signing key to a specific digital identity. This implementation
allows the use of a public key algorithm for server and user authentication, and allows SSH to verify the
identity of the owner of a key pair via digital certificates, signed and issued by a Certificate Authority (CA).

Server and User Authentication Using X.509v3


For server authentication, the Secure shell (SSH) server sends its own certificate to the SSH client for
verification. This server certificate is associated with the trustpoint configured in the server certificate profile
(ssh-server-cert-profile-server configuration mode).
For user authentication, the SSH client sends the user's certificate to the IOS SSH server for verification. The
SSH server validates the incoming user certificate using public key infrastructure (PKI) trustpoints configured
in the server certificate profile (ssh-server-cert-profile-user configuration mode).
By default, certificate-based authentication is enabled for server and user at the IOS SSH server end.

OCSP Response Stapling


The Online Certificate Status Protocol (OCSP) enables applications to determine the (revocation) state of an
identified certificate. This protocol specifies the data that needs to be exchanged between an application
checking the status of a certificate and the server providing that status. An OCSP client issues a status request
to an OCSP responder and suspends acceptance of the certificate until a response is received. An OCSP
response at a minimum consists of a responseStatus field that indicates the processing status of the a request.
For the public key algorithms, the key format consists of a sequence of one or more X.509v3 certificates
followed by a sequence of zero or more OCSP responses.
The X.509v3 Certificate for SSH Authentication feature uses OCSP Response Stapling. By using OCSP
response stapling, a device obtains the revocation information of its own certificate by contacting the OCSP
server and then stapling the result along with its certificates and sending the information to the peer rather
than having the peer contact the OCSP responder.

X.509v3 Certificates for SSH Authentication


2
X.509v3 Certificates for SSH Authentication
How to Configure X.509v3 Certificates for SSH Authentication

How to Configure X.509v3 Certificates for SSH Authentication


Configuring Digital Certificates for Server Authentication
Procedure

Command or Action Purpose


Step 1 enable Enables privileged EXEC mode.
Example: • Enter your password if prompted.

Device> enable

Step 2 configure terminal Enters global configuration mode.


Example:

Device# configure terminal

Step 3 ip ssh server algorithm hostkey Defines the order of host key algorithms. Only
{x509v3-ssh-rsa [ssh-rsa] | ssh-rsa the configured algorithm is negotiated with the
[x509v3-ssh-rsa]} Secure Shell (SSH) client.
Example: Note The IOS SSH server must have at
least one configured host key
Device(config)# ip ssh server algorithm algorithm:
hostkey x509v3-ssh-rsa
• x509v3-ssh-rsa:
certificate-based
authentication
• ssh-rsa: public key-based
authentication

Step 4 ip ssh server certificate profile Configures server and user certificate profiles
and enters SSH certificate profile configuration
Example:
mode.
Device(config)# ip ssh server
certificate profile

Step 5 server Configures server certificate profile and enters


SSH server certificate profile server
Example:
configuration mode.
Device(ssh-server-cert-profile)# server • The server profile is used to send out the
certificate of the server to the SSH client
during server authentication.

X.509v3 Certificates for SSH Authentication


3
X.509v3 Certificates for SSH Authentication
Configuring Digital Certificates for User Authentication

Command or Action Purpose


Step 6 trustpoint sign PKI-trustpoint-name Attaches the public key infrastructure (PKI)
trustpoint to the server certificate profile.
Example:
• The SSH server uses the certificate
Device(ssh-server-cert-profile-server)# associated with this PKI trustpoint for
trustpoint sign trust1 server authentication.

Step 7 ocsp-response include (Optional) Sends the Online Certificate Status


Protocol (OCSP) response or OCSP stapling
Example:
along with the server certificate.
Device(ssh-server-cert-profile-server)# Note By default, no OCSP response is
ocsp-response include sent along with the server
certificate.

Step 8 end Exits SSH server certificate profile server


configuration mode and returns to privileged
Example:
EXEC mode.
Device(ssh-server-cert-profile-server)#
end

Step 9 line vty line_number [ending_line_number] Enters line configuration mode to configure
the virtual terminal line settings. For
Example:
line_number and ending_line_number, specify
Device(config)# line vty line_number a pair of lines. The range is 0 to 15.
[ending_line_number]

Step 10 transport input ssh Specifies that the device prevent non-SSH
Telnet connections. This limits the router to
Example:
only SSH connections.
Device(config-line)#transport input ssh

Configuring Digital Certificates for User Authentication


Procedure

Command or Action Purpose


Step 1 enable Enables privileged EXEC mode.
Example: • Enter your password if prompted.

Device> enable

Step 2 configure terminal Enters global configuration mode.


Example:

Device# configure terminal

X.509v3 Certificates for SSH Authentication


4
X.509v3 Certificates for SSH Authentication
Configuring Digital Certificates for User Authentication

Command or Action Purpose


Step 3 ip ssh server algorithm authentication Defines the order of user authentication
{publickey | keyboard | password} algorithms. Only the configured algorithm is
negotiated with the Secure Shell (SSH) client.
Example:
Note • The IOS SSH server must
Device(config)# ip ssh server algorithm have at least one configured
authentication publickey user authentication algorithm.
• To use the certificate method
for user authentication, the
publickey keyword must be
configured.

Step 4 ip ssh server algorithm publickey Defines the order of public key algorithms.
{x509v3-ssh-rsa [ssh-rsa] | ssh-rsa Only the configured algorithm is accepted by
[x509v3-ssh-rsa]} the SSH client for user authentication.
Example: Note The IOS SSH client must have at
least one configured public key
Device(config)# ip ssh server algorithm algorithm:
publickey x509v3-ssh-rsa
• x509v3-ssh-rsa:
Certificate-based
authentication
• ssh-rsa: Public-key-based
authentication

Step 5 ip ssh server certificate profile Configures server certificate profile and user
certificate profile and enters SSH certificate
Example:
profile configuration mode.
Device(config)# ip ssh server
certificate profile

Step 6 user Configures user certificate profile and enters


SSH server certificate profile user
Example:
configuration mode.
Device(ssh-server-cert-profile)# user

Step 7 trustpoint verify PKI-trustpoint-name Configures the public key infrastructure (PKI)
trustpoint that is used to verify the incoming
Example:
user certificate.
Device(ssh-server-cert-profile-user)# Note Configure multiple trustpoints by
trustpoint verify trust2 executing the same command
multiple times. A maximum of 10
trustpoints can be configured.

X.509v3 Certificates for SSH Authentication


5
X.509v3 Certificates for SSH Authentication
Verifying the Server and User Authentication Using Digital Certificates

Command or Action Purpose


Step 8 ocsp-response required (Optional) Mandates the presence of the Online
Certificate Status Protocol (OCSP) response
Example:
with the incoming user certificate.
Device(ssh-server-cert-profile-user)# Note By default, the user certificate is
ocsp-response required accepted without an OCSP
response.

Step 9 end Exits SSH server certificate profile user


configuration mode and returns to privileged
Example:
EXEC mode.
Device(ssh-server-cert-profile-user)#
end

Step 10 line vty line_number [ending_line_number] Enters line configuration mode to configure
the virtual terminal line settings. For
Example:
line_number and ending_line_number, specify
Device(config)# line vty line_number a pair of lines. The range is 0 to 15.
[ending_line_number]

Step 11 transport input ssh Specifies that the device prevent non-SSH
Telnet connections. This limits the router to
Example:
only SSH connections.
Device(config-line)#transport input ssh

Verifying the Server and User Authentication Using Digital


Certificates
Procedure

Step 1 enable
Enables privileged EXEC mode.
• Enter your password if prompted.

Example:

Device> enable

Step 2 show ip ssh


Displays the currently configured authentication methods. To confirm the use of certificate-based authentication,
ensure that the x509v3-ssh-rsa algorithm is the configured host key algorithm.
Example:

X.509v3 Certificates for SSH Authentication


6
X.509v3 Certificates for SSH Authentication
Verifying the Server and User Authentication Using Digital Certificates

Device# show ip ssh

SSH Enabled - version 1.99


Authentication methods:publickey,keyboard-interactive,password
Authentication Publickey Algorithms:x509v3-ssh-rsa,ssh-rsa
Hostkey Algorithms:x509v3-ssh-rsa,ssh-rsa
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 1024 bits

Step 3 debug ip ssh detail


Turns on debugging messages for SSH details.
Example:
Device# debug ip ssh detail

ssh detail messages debugging is on

Step 4 show log


Shows the debug message log.
Example:
Device# show log

Syslog logging: enabled (0 messages dropped, 9 messages rate-limited, 0 flushes, 0 overruns,


xml disabled, filtering disabled)

No Active Message Discriminator.

No Inactive Message Discriminator.

Console logging: disabled


Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 233 messages logged, xml disabled,
filtering disabled
Exception Logging: size (4096 bytes)
Count and timestamp logging messages: disabled
File logging: disabled
Persistent logging: disabled

No active filter modules.

Trap logging: level informational, 174 message lines logged


Logging Source-Interface: VRF Name:

Log Buffer (4096 bytes):


5 IST: SSH2 CLIENT 0: SSH2_MSG_KEXINIT sent
*Sep 6 14:44:08.496 IST: SSH0: protocol version id is - SSH-1.99-Cisco-1.25
*Sep 6 14:44:08.496 IST: SSH2 0: kexinit sent: kex algo =
diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
*Sep 6 14:44:08.496 IST: SSH2 0: Server certificate trustpoint not found. Skipping hostkey
algo = x509v3-ssh-rsa
*Sep 6 14:44:08.496 IST: SSH2 0: kexinit sent: hostkey algo = ssh-rsa
*Sep 6 14:44:08.496 IST: SSH2 0: kexinit sent: encryption algo =
aes128-ctr,aes192-ctr,aes256-ctr
*Sep 6 14:44:08.496 IST: SSH2 0: kexinit sent: mac algo =

X.509v3 Certificates for SSH Authentication


7
X.509v3 Certificates for SSH Authentication
Verifying the Server and User Authentication Using Digital Certificates

hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha1-96
*Sep 6 14:44:08.496 IST: SSH2 0: SSH2_MSG_KEXINIT sent
*Sep 6 14:44:08.496 IST: SSH2 0: SSH2_MSG_KEXINIT received
*Sep 6 14:44:08.496 IST: SSH2 0: kex: client->server enc:aes128-ctr mac:hmac-sha2-256
*Sep 6 14:44:08.496 IST: SSH2 0: kex: server->client enc:aes128-ctr mac:hmac-sha2-256
*Sep 6 14:44:08.496 IST: SSH2 0: Using hostkey algo = ssh-rsa
*Sep 6 14:44:08.496 IST: SSH2 0: Using kex_algo = diffie-hellman-group-exchange-sha1
*Sep 6 14:44:08.497 IST: SSH2 CLIENT 0: SSH2_MSG_KEXINIT received
*Sep 6 14:44:08.497 IST: SSH2 CLIENT 0: kex: server->client enc:aes128-ctr mac:hmac-sha2-256

*Sep 6 14:44:08.497 IST: SSH2 CLIENT 0: kex: client->server enc:aes128-ctr mac:hmac-sha2-256

*Sep 6 14:44:08.497 IST: SSH2 CLIENT 0: Using hostkey algo = ssh-rsa


*Sep 6 14:44:08.497 IST: SSH2 CLIENT 0: Using kex_algo = diffie-hellman-group-exchange-sha1
*Sep 6 14:44:08.497 IST: SSH2 CLIENT 0: SSH2_MSG_KEX_DH_GEX_REQUEST sent
*Sep 6 14:44:08.497 IST: SSH2 CLIENT 0: Range sent- 2048 < 2048 < 4096
*Sep 6 14:44:08.497 IST: SSH2 0: SSH2_MSG_KEX_DH_GEX_REQUEST received
*Sep 6 14:44:08.497 IST: SSH2 0: Range sent by client is - 2048 < 2048 < 4096
*Sep 6 14:44:08.497 IST: SSH2 0: Modulus size established : 2048 bits
*Sep 6 14:44:08.510 IST: SSH2 0: expecting SSH2_MSG_KEX_DH_GEX_INIT
*Sep 6 14:44:08.510 IST: SSH2 CLIENT 0: SSH2_MSG_KEX_DH_GEX_GROUP received
*Sep 6 14:44:08.510 IST: SSH2 CLIENT 0: Server has chosen 2048 -bit dh keys
*Sep 6 14:44:08.523 IST: SSH2 CLIENT 0: expecting SSH2_MSG_KEX_DH_GEX_REPLY
*Sep 6 14:44:08.524 IST: SSH2 0: SSH2_MSG_KEXDH_INIT received
*Sep 6 14:44:08.555 IST: SSH2: kex_derive_keys complete
*Sep 6 14:44:08.555 IST: SSH2 0: SSH2_MSG_NEWKEYS sent
*Sep 6 14:44:08.555 IST: SSH2 0: waiting for SSH2_MSG_NEWKEYS
*Sep 6 14:44:08.555 IST: SSH2 CLIENT 0: SSH2_MSG_KEX_DH_GEX_REPLY received
*Sep 6 14:44:08.555 IST: SSH2 CLIENT 0: Skipping ServerHostKey Validation
*Sep 6 14:44:08.571 IST: SSH2 CLIENT 0: signature length 271
*Sep 6 14:44:08.571 IST: SSH2: kex_derive_keys complete
*Sep 6 14:44:08.571 IST: SSH2 CLIENT 0: SSH2_MSG_NEWKEYS sent
*Sep 6 14:44:08.571 IST: SSH2 CLIENT 0: waiting for SSH2_MSG_NEWKEYS
*Sep 6 14:44:08.571 IST: SSH2 CLIENT 0: SSH2_MSG_NEWKEYS received
*Sep 6 14:44:08.571 IST: SSH2 0: SSH2_MSG_NEWKEYS received
*Sep 6 14:44:08.571 IST: SSH2 0: Authentications that can continue =
publickey,keyboard-interactive,password
*Sep 6 14:44:08.572 IST: SSH2 0: Using method = none
*Sep 6 14:44:08.572 IST: SSH2 0: Authentications that can continue =
publickey,keyboard-interactive,password
*Sep 6 14:44:08.572 IST: SSH2 0: Using method = keyboard-interactive
*Sep 6 14:44:11.983 IST: SSH2 0: authentication successful for cisco
*Sep 6 14:44:11.984 IST: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: cisco] [Source:
192.168.121.40] [localport: 22] at 14:44:11 IST Thu Sep 6 2018
*Sep 6 14:44:11.984 IST: SSH2 0: channel open request
*Sep 6 14:44:11.985 IST: SSH2 0: pty-req request
*Sep 6 14:44:11.985 IST: SSH2 0: setting TTY - requested: height 24, width 80; set: height
24, width 80
*Sep 6 14:44:11.985 IST: SSH2 0: shell request
*Sep 6 14:44:11.985 IST: SSH2 0: shell message received
*Sep 6 14:44:11.985 IST: SSH2 0: starting shell for vty
*Sep 6 14:44:22.066 IST: %SYS-6-LOGOUT: User cisco has exited tty session 1(192.168.121.40)
*Sep 6 14:44:22.166 IST: SSH0: Session terminated normally
*Sep 6 14:44:22.167 IST: SSH CLIENT0: Session terminated normally

Step 5 debug ip packet


Turns on debugging for IP packet details.
Example:
Device# debug ip packet

Step 6 show log

X.509v3 Certificates for SSH Authentication


8
X.509v3 Certificates for SSH Authentication
Verifying the Server and User Authentication Using Digital Certificates

Shows the debug message log.


Example:
Device# show log

yslog logging: enabled (0 messages dropped, 9 messages rate-limited, 0 flushes, 0 overruns,


xml disabled, filtering disabled)

No Active Message Discriminator.

No Inactive Message Discriminator.

Console logging: disabled


Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 1363 messages logged, xml disabled,
filtering disabled
Exception Logging: size (4096 bytes)
Count and timestamp logging messages: disabled
File logging: disabled
Persistent logging: disabled

No active filter modules.

Trap logging: level informational, 176 message lines logged


Logging Source-Interface: VRF Name:

Log Buffer (4096 bytes):


bleid=0, s=192.168.121.40 (local), d=192.168.121.40 (FortyGigabitEthernet1/0/1), routed via
RIB
*Sep 6 14:45:45.177 IST: IP: s=192.168.121.40 (local), d=192.168.121.40
(FortyGigabitEthernet1/0/1), len 40, sending
*Sep 6 14:45:45.177 IST: IP: s=192.168.121.40 (local), d=192.168.121.40
(FortyGigabitEthernet1/0/1), len 40, output feature, NAT Inside(8), rtype 1, forus FALSE,
sendself FALSE, mtu 0, fwdchk FALSE
*Sep 6 14:45:45.177 IST: IP: tableid=0, s=192.168.121.40 (FortyGigabitEthernet1/0/1),
d=192.168.121.40 (FortyGigabitEthernet1/0/1), routed via RIB
*Sep 6 14:45:45.177 IST: IP: tableid=0, s=192.168.121.40 (FortyGigabitEthernet1/0/1),
d=192.168.121.40 (FortyGigabitEthernet1/0/1), routed via RIB
*Sep 6 14:45:45.177 IST: IP: s=192.168.121.40 (local), d=192.168.121.40, len 40, local
feature, feature skipped, NAT(2), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Sep 6 14:45:45.178 IST: IP: tableid=0, s=192.168.121.40 (local), d=192.168.121.40
(FortyGigabitEthernet1/0/1), routed via RIB
*Sep 6 14:45:45.178 IST: IP: s=192.168.121.40 (local), d=192.168.121.40
(FortyGigabitEthernet1/0/1), len 40, sending
*Sep 6 14:45:45.178 IST: IP: s=192.168.121.40 (local), d=192.168.121.40
(FortyGigabitEthernet1/0/1), len 40, output feature, NAT Inside(8), rtype 1, forus FALSE,
sendself FALSE, mtu 0, fwdchk FALSE
*Sep 6 14:45:45.178 IST: IP: tableid=0, s=192.168.121.40 (FortyGigabitEthernet1/0/1),
d=192.168.121.40 (FortyGigabitEthernet1/0/1), routed via RIB
*Sep 6 14:45:45.178 IST: IP: s=192.168.121.40 (local), d=192.168.121.40, len 40, local
feature, feature skipped, NAT(2), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Sep 6 14:45:45.178 IST: IP: tableid=0, s=192.168.121.40 (local), d=192.168.121.40
(FortyGigabitEthernet1/0/1), routed via RIB
*Sep 6 14:45:45.178 IST: IP: s=192.168.121.40 (local), d=192.168.121.40
(FortyGigabitEthernet1/0/1), len 40, sending
*Sep 6 14:45:45.178 IST: IP: s=192.168.121.40 (local), d=192.168.121.40
(FortyGigabitEthernet1/0/1), len 40, output feature, NAT Inside(8), rtype 1, forus FALSE,
sendself FALSE, mtu 0, fwdchk FALSE
*Sep 6 14:45:45.178 IST: IP: tableid=0, s=192.168.121.40 (FortyGigabitEthernet1/0/1),
d=192.168.121.40 (FortyGigabitEthernet1/0/1), routed via RIB

X.509v3 Certificates for SSH Authentication


9
X.509v3 Certificates for SSH Authentication
Configuration Examples for X.509v3 Certificates for SSH Authentication

*Sep 6 14:45:45.178 IST: IP: tableid=0, s=192.168.121.40 (FortyGigabitEthernet1/0/1),


d=192.168.121.40 (FortyGigabitEthernet1/0/1), routed via RIB
*Sep 6 14:45:45.178 IST: IP: tableid=0, s=192.168.121.40 (FortyGigabitEthernet1/0/1),
d=192.168.121.40 (FortyGigabitEthernet1/0/1), routed via RIB
*Sep 6 14:45:45.178 IST: IP: s=192.168.121.40 (local), d=192.168.121.40, len 40, local
feature, feature skipped, NAT(2), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Sep 6 14:45:45.178 IST: IP: tableid=0, s=192.168.121.40 (local), d=192.168.121.40
(FortyGigabitEthernet1/0/1), routed via RIB
*Sep 6 14:45:45.178 IST: IP: s=192.168.121.40 (local), d=192.168.121.40
(FortyGigabitEthernet1/0/1), len 40, sending
*Sep 6 14:45:45.178 IST: IP: s=192.168.121.40 (local), d=192.168.121.40
(FortyGigabitEthernet1/0/1), len 40, output feature, NAT Inside(8), rtype 1, forus FALSE,
sendself FALSE, mtu 0, fwdchk FALSE
*Sep 6 14:45:45.179 IST: IP: tableid=0, s=192.168.121.40 (FortyGigabitEthernet1/0/1),
d=192.168.121.40 (FortyGigabitEthernet1/0/1), routed via RIB
*Sep 6 14:45:45.179 IST: IP: s=192.168.121.40 (local), d=192.168.121.40, len 40, local
feature, feature skipped, NAT(2), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Sep 6 14:45:45.179 IST: IP: tableid=0, s=192.168.121.40 (local), d=192.168.121.40
(FortyGigabitEthernet1/0/1), routed via RIB
*Sep 6 14:45:45.179 IST: IP: s=192.168.121.40 (local), d=192.168.121.40
(FortyGigabitEthernet1/0/1), len 40, sending
*Sep 6 14:45:45.179 IST: IP: s=192.168.121.40 (local), d=192.168.121.40
(FortyGigabitEthernet1/0/1), len 40, output feature, NAT Inside(8), rtype 1, forus FALSE,
sendself FALSE, mtu 0, fwdchk FALSE
*Sep 6 14:45:45.179 IST: IP: tableid=0, s=192.168.121.40 (FortyGigabitEthernet1/0/1),
d=192.168.121.40 (FortyGigabitEthernet1/0/1), routed via RIB

Configuration Examples for X.509v3 Certificates for SSH


Authentication
Example: Configuring Digital Certificates for Server Authentication

Device> enable
Device# configure terminal
Device(config)# ip ssh server algorithm hostkey x509v3-ssh-rsa
Device(config)# ip ssh server certificate profile
Device(ssh-server-cert-profile)# server
Device(ssh-server-cert-profile-server)# trustpoint sign trust1
Device(ssh-server-cert-profile-server)# exit

Example: Configuring Digital Certificate for User Authentication

Device> enable
Device# configure terminal
Device(config)# ip ssh server algorithm authentication publickey
Device(config)# ip ssh server algorithm publickey x509v3-ssh-rsa
Device(config)# ip ssh server certificate profile
Device(ssh-server-cert-profile)# user
Device(ssh-server-cert-profile-user)# trustpoint verify trust2

X.509v3 Certificates for SSH Authentication


10
X.509v3 Certificates for SSH Authentication
Additional References for X.509v3 Certificates for SSH Authentication

Device(ssh-server-cert-profile-user)# end

Additional References for X.509v3 Certificates for SSH


Authentication
Related Documents

Related Topic Document Title

For complete syntax and usage information for Consolidated Platform Command Reference, Cisco IOS
the commands used in this chapter. Release 15.2(7)E (Catalyst 1000 Switches)

PKI configuration Configuring and Managing a Cisco IOS Certificate Server


for PKI Deployment

Technical Assistance

Description Link
The Cisco Support website provides extensive online resources, including http://www.cisco.com/support
documentation and tools for troubleshooting and resolving technical issues
with Cisco products and technologies.
To receive security and technical information about your products, you can
subscribe to various services, such as the Product Alert Tool (accessed from
Field Notices), the Cisco Technical Services Newsletter, and Really Simple
Syndication (RSS) Feeds.
Access to most tools on the Cisco Support website requires a Cisco.com user
ID and password.

Feature History for X.509v3 Certificates for SSH Authentication


This table provides release and related information for features explained in this module.
These features are available on all releases subsequent to the one they were introduced in, unless noted
otherwise.

Release Feature Feature Information

Cisco IOS Release 15.2(7)E1 X.509v3 Certificates for SSH The X.509v3 Certificates for SSH
Authentication Authentication feature uses the X.509v3
digital certificates in server and user
authentication at the SSH server side.

Use Cisco Feature Navigator to find information about platform and software image support. To access Cisco
Feature Navigator, go to http://www.cisco.com/go/cfn.

X.509v3 Certificates for SSH Authentication


11
X.509v3 Certificates for SSH Authentication
Feature History for X.509v3 Certificates for SSH Authentication

X.509v3 Certificates for SSH Authentication


12

You might also like