Secure Shell (SSH) is
an application and a protocol that provides a secure replacement to the
Berkeley r-tools. The protocol secures sessions using standard cryptographic
mechanisms, and the application can be used similarly to the Berkeley
Two versions of the
SSH server are available: SSH Version 1 (SSHv1) and SSH Version 2 (SSHv2).
SSHv1 uses Rivest, Shamir, and Adelman (RSA) keys and SSHv2 uses Digital
Signature Algorithm (DSA) keys.
Cisco IOS XR software supports both SSHv1 and SSHv2.
This module describes
how to implement Secure Shell on the
For a complete
description of the Secure Shell commands used in this
, see the
System Security Command Reference for Cisco NCS 6000 Series Routers.
The following prerequisites are required to implement Secure Shell:
You must be in a user group associated with a task group that
includes the proper task IDs. The command reference guides include the task IDs
required for each command. If you suspect user group assignment is preventing
you from using a command, contact your AAA administrator for assistance.
Download the required image on your router. The SSH server and SSH client require you
to have a a crypto package (data encryption standard [DES], 3DES and AES) from Cisco
downloaded on your router.
To run an SSHv2 server, you must have a VRF. This may be the default VRF or a
specific VRF. VRF changes are applicable only to the SSH v2 server.
Configure user authentication for local or remote access. You can configure
authentication with or without authentication, authorization, and accounting (AAA).
For more information, see the Authentication, Authorization, and Accounting
Cisco IOS XR Software
module in the
System Security Command Reference for Cisco NCS 6000 Series Routers publication and Configuring AAA Services on
Cisco IOS XR Software
module in the
System Security Configuration Guide for Cisco NCS 6000 Series Routers publication.
AAA authentication and authorization must be configured correctly for Secure Shell
File Transfer Protocol (SFTP) to work.
Restrictions for Implementing Secure Shell
The following are some basic SSH restrictions and limitations of the SFTP feature:
A VRF is not accepted as inband if that VRF is already set as an out-of-band VRF. SSH v1 continues to bind only to the default VRF.
In order for an outside client to connect to the router, the router needs to have an RSA (for SSHv1) or DSA (for SSHv2) key pair configured. DSA and RSA keys are not required if you are initiating an SSH client connection from the router to an outside routing device. The same is true for SFTP: DSA and RSA keys are not required because SFTP operates only in client mode.
In order for SFTP to work properly, the remote SSH server must enable the SFTP server functionality. For example, the SSHv2 server is configured to handle the SFTP subsystem with a line such as /etc/ssh2/sshd2_config:
The SFTP server is usually included as part of SSH packages from public domain and is turned on by default configuration.
SFTP is compatible with sftp server version OpenSSH_2.9.9p2 or higher.
RSA-based user authentication is supported in the SSH and SFTP servers. The support however, is not extended to the SSH client.
Execution shell and SFTP are the only applications supported.
The AES encryption algorithm is supported on the SSHv2 server and client, but not on the SSHv1 server and client. Any requests for an AES cipher sent by an SSHv2 client to an SSHv1 server are ignored, with the server using 3DES instead.
The SFTP client does not support remote filenames containing wildcards (*
?, ). The user must issue the sftp command multiple times or list all of the source files from the remote host to download them on to the router. For uploading, the router SFTP client can support multiple files specified using a wildcard provided that the issues mentioned in the first through third bullets in this section are resolved.
The cipher preference for the SSH server follows the order AES128, AES192, AES256, and, finally, 3DES. The server rejects any requests by the client for an unsupported cipher, and the SSH session does not proceed.
Use of a terminal type other than vt100 is unsupported, and the software generates a warning message in this case.
Password messages of “none” are unsupported on the SSH client.
Because the router infrastructure does not provide support for UNIX-like file permissions, files created on the local device lose the original permission information. For files created on the remote file system, the file permission adheres to the umask on the destination host and the modification and last access times are the time of the copy.
Information About Implementing Secure Shell
To implement SSH, you should understand the following concepts:
The SSH server feature enables an SSH client to make a secure, encrypted connection to a Cisco router. This connection provides functionality that is similar to that of an inbound Telnet connection. Before SSH, security was limited to Telnet security. SSH allows a strong encryption to be used with the Cisco IOS XR software authentication. The SSH server in Cisco IOS XR software works with publicly and commercially available SSH clients.
The SSH client feature
is an application running over the SSH protocol to provide device
authentication and encryption. The SSH client enables a Cisco router to make a
secure, encrypted connection to another Cisco router or to any other device
running the SSH server. This connection provides functionality that is similar
to that of an outbound Telnet connection except that the connection is
encrypted. With authentication and encryption, the SSH client allows for a
secure communication over an insecure network.
The SSH client in the
Cisco IOS XR software worked with publicly and commercially
available SSH servers. The SSH client supported the ciphers of AES, 3DES,
message digest algorithm 5 (MD5), SHA1, and password authentication. User
authentication was performed in the Telnet session to the router. The user
authentication mechanisms supported for SSH were RADIUS, TACACS+, and the use
of locally stored usernames and passwords.
The SSH client supports setting DSCP value in the outgoing packets.
ssh client dscp <value from 0 – 63>
If not configured, the default DSCP value set in packets is 16 (for
both client and server).
The SSH client supports the following options:
DSCP—DSCP value for SSH
client Provide SSH client service
server Provide SSH server service
timeout Set timeout value for SSH
RP/0/5/CPU0:router(config)#ssh client ?
Knownhost—Enable the host
pubkey check by local database.
interface for SSH client sessions.
RP/0/5/CPU0:router(config)#ssh client source-interface ?
ATM ATM Network Interface(s)
BVI Bridge-Group Virtual Interface
Bundle-Ether Aggregated Ethernet interface(s)
Bundle-POS Aggregated POS interface(s)
CEM Circuit Emulation interface(s)
GigabitEthernet GigabitEthernet/IEEE 802.3 interface(s)
IMA ATM Network Interface(s)
IMtestmain IM Test Interface
Loopback Loopback interface(s)
MgmtEth Ethernet/IEEE 802.3 interface(s)
Multilink Multilink network interface(s)
Null Null interface
PFItestmain PFI Test Interface
PFItestnothw PFI Test Not-HW Interface
POS Packet over SONET/SDH network interface(s)
PW-Ether PWHE Ethernet Interface
PW-IW PWHE VC11 IP Interworking Interface
Serial Serial network interface(s)
VASILeft VASI Left interface(s)
VASIRight VASI Right interface(s)
test-bundle-channel Aggregated Test Bundle interface(s)
tunnel-ipsec IPSec Tunnel interface(s)
tunnel-mte MPLS Traffic Engineering P2MP Tunnel interface(s)
tunnel-te MPLS Traffic Engineering Tunnel interface(s)
tunnel-tp MPLS Transport Protocol Tunnel interface
RP/0/5/CPU0:router(config)#ssh client source-interface
VRF—Source interface VRF for
SSH client sessions:
RP/0/5/CPU0:router(config)#ssh client vrf ?
WORD VRF name (max:32 chars)
RP/0/5/CPU0:router(config)#ssh client vrf shan ?
RP/0/5/CPU0:router(config)#ssh client vrf shan
SSH also supports remote command execution as follows:
A.B.C.D IPv4 (A.B.C.D) address
WORD Hostname of the remote node
X:X::X IPv6 (A:B:C:D...:D) address
vrf vrf table for the route lookup
RP/0/5/CPU0:router#ssh 220.127.116.11 ?
cipher Accept cipher type
command Specify remote command (non-interactive)
source-interface Specify source interface
username Accept userid for authentication
RP/0/5/CPU0:router#ssh 18.104.22.168 username admin command "show redundancy sum"
Wed Jan 9 07:05:27.997 PST
Active Node Standby Node
0/4/CPU0 0/5/CPU0 (Node Ready, NSR: Not Configured)
SSH includes support
for standard file transfer protocol (SFTP) , a new standard file transfer
protocol introduced in SSHv2. This feature provides a secure and authenticated
method for copying router configuration or router image files.
The SFTP client
functionality is provided as part of the SSH component and is always enabled on
the router. Therefore, a user with the appropriate level can copy files to and
from the router. Like the
can be used only in
XR EXEC mode.
The SFTP client is
VRF-aware, and you may configure the secure FTP client to use the VRF
associated with a particular source interface during connections attempts. The
SFTP client also supports interactive mode, where the user can log on to the
server to perform specific tasks via the Unix server.
The SFTP Server is a
sub-system of the SSH server. In other words, when an SSH server receives an
SFTP server request, the SFTP API creates the SFTP server as a child process to
the SSH server. A new SFTP server instance is created with each new request.
The SFTP requests for
a new SFTP server in the following steps:
The user runs the
with the required arguments
The SFTP API
internally creates a child session that interacts with the SSH server
The SSH server
creates the SFTP server child process
The SFTP server
and client interact with each other in an encrypted format
The SFTP transfer is subject to LPTS policer "SSH-Known". Low
policer values will affect SFTP transfer speeds
In IOS-XR SW release 4.3.1 onwards the default policer value for
SSH-Known has been reset from 2500pps to 300pps. Slower transfers are expected
due to this change. You can adjust the lpts policer value for this punt cause
to higher values that will allow faster transfers
When the SSH server
establishes a new connection with the SSH client, the server daemon creates a
new SSH server child process. The child server process builds a secure
communications channel between the SSH client and server via key exchange and
user authentication processes. If the SSH server receives a request for the
sub-system to be an SFTP server, the SSH server daemon creates the SFTP server
child process. For each incoming SFTP server subsystem request, a new SSH
server child and a SFTP server instance is created. The SFTP server
authenticates the user session and initiates a connection. It sets the
environment for the client and the default directory for the user.
initialization occurs, the SFTP server waits for the SSH_FXP_INIT message from
the client, which is essential to start the file communication session. This
message may then be followed by any message based on the client request. Here,
the protocol adopts a 'request-response' model, where the client sends a
request to the server; the server processes this request and sends a response.
The SFTP server
displays the following responses:
The server must be
running in order to accept incoming SFTP connections.
RSA Based Host Authentication
Verifying the authenticity of a server is the first step to a secure SSH connection. This process is called the host authentication, and is conducted to ensure that a client connects to a valid server.
The host authentication is performed using the public key of a server. The server, during the key-exchange phase, provides its public key to the client. The client checks its database for known hosts of this server and the corresponding public-key. If the client fails to find the server's IP address, it displays a warning message to the user, offering an option to either save the public key or discard it. If the server’s IP address is found, but the public-key does not match, the client closes the connection. If the public key is valid, the server is verified and a secure SSH connection is established.
The IOS XR SSH server and client had support for DSA based host authentication. But for compatibility with other products, like IOS, RSA based host authentication support is also added.
RSA Based User Authentication
One of the method for authenticating the user in SSH protocol is RSA public-key based user
authentication. The possession of a private key serves as the authentication of the user.
This method works by sending a signature created with a private key of the user. Each user
has a RSA keypair on the client machine. The private key of the RSA keypair remains on the
The user generates an RSA public-private key pair on a unix client using a standard key
generation mechanism such as ssh-keygen. The max length of the keys supported is 2048 bits,
and the minimum length is 512 bits. The following example displays a typical key generation
bash-2.05b$ ssh-keygen –b 1024 –t rsa
Generating RSA private key, 1024 bit long modulus
The public key must be in base64 encoded (binary) format for it to be imported correctly
into the box. You can use third party tools available on the Internet to convert the key to
the binary format.
Once the public key is imported to the router, the SSH client can choose to use the public
key authentication method by specifying the request using the “-o” option in the SSH
client. For example:
If a public key is not imported to a router using the RSA method, the SSH server initiates
the password based authentication. If a public key is imported, the server proposes the use
of both the methods. The SSH client then chooses to use either method to establish the
connection. The system allows only 10 outgoing SSH client connections.
Currently, only SSH version 2 and SFTP server support the RSA based authentication. For
more information on how to import the public key to the router, see the Implementing
Certification Authority Interoperability on
chapter in this
The preferred method of authentication would be as stated in the SSH RFC. The RSA based
authentication support is only for local authentication, and not for TACACS/RADIUS
Authentication, Authorization, and Accounting (AAA) is a suite of network security services
that provide the primary framework through which access control can be set up on your Cisco
router or access server. For more information on AAA, see the Authentication,
Authorization, and Accounting Commands on
module in the
System Security Command Reference for Cisco NCS 6000 Series Routers
publication and the Configuring AAA Services on
module in the
System Security Configuration Guide for Cisco NCS 6000 Series Routers
SSHv2 Client Keyboard-Interactive Authentication
An authentication method in which the authentication information is entered using a keyboard is known as keyboard-interactive authentication. This method is an interactive authentication method in the SSH protocol. This type of authentication allows the SSH client to support different methods of authentication without having to be aware of their underlying mechanisms.
Currently, the SSHv2 client supports the keyboard-interactive authentication. This type of authentication works only for interactive applications.
The password authentication is the default authentication method. The keyboard-interactive authentication method is selected if the server is configured to support only the keyboard-interactive authentication.
How to Implement Secure Shell
To configure SSH, perform the tasks described in the following sections:
the RSA key pair, use the
zeroize rsa command.
is used for SSHv1 only.
RP/0/RP0/CPU0:router# crypto key generate dsa
Enables the SSH
server for local and remote authentication on the router.
recommended minimum modulus size is 1024 bits.
DSA key pair.
the DSA key pair, use the
is used only for SSHv2.
XR Config mode.
RP/0/RP0/CPU0:router(config)# ssh timeout 60
Configures the timeout value for user authentication to AAA.
user fails to authenticate itself to AAA within the configured time, the
connection is aborted.
value is configured, the default value of 30 seconds is used. The range is from
5 to 120.
Do one of the
ssh server v2
RP/0/RP0/CPU0:router(config)# ssh server v2
Brings up an SSH server using a specified VRF of up to 32 characters. If no VRF
is specified, the default VRF is used.
the SSH server from receiving any further connections for the specified VRF,
form of this command. If no VRF is specified, the default is assumed.
server can be configured for multiple VRF usage.
Forces the SSH server to accept only SSHv2 clients if you configure the SSHv2
option by using the
ssh server v2
command. If you choose the
ssh server v2
command, only the SSH v2 client connections are accepted.
commit—Saves the configuration changes and remains
within the configuration session.
end—Prompts user to take one of these actions:
Yes— Saves configuration changes and exits the
No—Exits the configuration session without
committing the configuration changes.
Cancel—Remains in the configuration mode, without
committing the configuration changes.
RP/0/RP0/CPU0:router# show ssh
Displays all of the incoming and outgoing SSHv1 and SSHv2 connections to the
RP/0/RP0/CPU0:router# show ssh session details
Displays a detailed report of the SSHv2 connections to and from the router.
To run an
SSHv2 server, you must have a VRF. This may be the default or a specific VRF.
VRF changes are applicable only to the SSH v2 server.
client tries to make an SSHv2 connection to the remote peer. If the remote peer
supports only the SSHv1 server, the peer internally spawns an SSHv1 connection
to the remote server.
des option can be used only with an SSHv1 client.
client supports only the 3DES encryption algorithm option, which is still
available by default for those SSH clients only.
hostname argument is used and the host has both IPv4 and
IPv6 addresses, the IPv6 address is used.
If you are
using SSHv1 and your SSH connection is being rejected, you have not
successfully generated an RSA key pair for your router. Make sure that you have
specified a hostname and domain. Then use the
command to generate an RSA key pair and enable the SSH server.
If you are
using SSHv2 and your SSH connection is being rejected, you have not
successfully generated a DSA key pair for your router. Make sure that you have
specified a hostname and domain. Then use the
command to generate a DSA key pair and enable the SSH server.
When configuring the RSA or
DSA key pair, you might encounter the following error messages:
configure a hostname for the router using the
configure a host domain for the router using the
The number of
allowable SSH connections is limited to the maximum number of virtual terminal
lines configured for the router. Each SSH connection uses a vty resource.
either local security or the security protocol that is configured through AAA
on your router for user authentication. When configuring AAA, you must ensure
that the console is not running under AAA by applying a keyword in the global
configuration mode to disable AAA on the console.
Configuration Examples for Implementing Secure Shell
This section provides the following configuration example:
The following example shows how to configure SSHv2 by creating a hostname, defining a
domain name, enabling the SSH server for local and remote authentication on the router
by generating a DSA key pair, bringing up the SSH server, and saving the configuration
commands to the running configuration file.
After SSH has been configured, the SFTP feature is available on the router.
domain name cisco.com
crypto key generate dsa
The following sections provide references related to implementing secure shell.
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.
The Cisco Technical Support website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.