Cisco Configuring Secure Shell (SSH) on Cisco IOS Router

(1)

(2)

Configuring Secure Shell (SSH) on Cisco

IOS

®

Routers

Introduction

Hardware and Software Versions

SSHv1 vs. SSHv2

Network Diagram

Testing Authentication

Testing Authentication Without SSH

Testing Authentication With SSH

Optional Configuration Settings

Preventing Non−SSH Connections

Setting Up an IOS Router as an SSH Client

Adding SSH Terminal−Line Access

debug

and

show

Commands

Sample Debug Output

What Can Go Wrong

Tools Information

Related Information

Introduction

This document discusses configuring and debugging Secure Shell (SSH) on a Cisco router running a version

of Cisco IOS

®

Software that supports SSH. See below for more information on specific versions and software

images.

Hardware and Software Versions

The information in this document is based on the software version below.

Cisco IOS

®

3600 Software (C3640−IK9S−M), Version 12.2(2)T1

• SSH was introduced into IOS platforms/images as shown below.

SSH Version 1.0 (SSHv1) server was introduced in some IOS platforms/images starting in 12.0.5.S.

• SSH client was introduced in some IOS platforms/images starting in 12.1.3.T.

• SSH terminal−line access (also known as reverse−telnet) was introduced in some IOS

platforms/images starting in 12.2.2.T.

• For a complete list of feature sets supported in different Cisco IOS versions and on different platforms, refer

(4)

to the Feature Navigator tool described in the Tools Information section.

SSHv1 vs. SSHv2

At this time, IOS only supports SSHv1; Cisco has no plans to implement SSHv2. There are several reasons

for this, as explained below.

Primarily, Cisco wishes to keep its engineering talent working on core features within devices rather than

developing and maintaining other features that provide infrastructure security through encryption. Cisco

implemented SSH in Cisco IOS when IP Security (IPSec) was being developed through the Internet

Engineering Task Force (IETF). IPSec is a core feature, while the implementation of SSH in IOS was more

of a tactical move to provide a secure method of accessing routers during the IPSec development process.

Cisco dedicates staff to maintaining the SSH feature for fixes, but requests for enhancements will be given

low priority. Cisco is committed to deploying IPSec for securing all traffic, including management traffic to

and from Cisco network devices.

If vulnerabilities are found in the protocol or implementation of SSHv1, their review will be given top

priority, as will all potential security vulnerabilities. Note that Cisco IOS code is not the same as the code

found in UNIX, Windows, or any other devices. As such, a coding problem in one of those implementations

most likely will not be found in Cisco IOS. Additionally, not all SSHv1 features can be found in the Cisco

implementations. Notably, SSH in Cisco IOS does not provide "session forwarding", nor does it provide

tunnelling of X11. Defects in these parts of the common code will not be a problem in Cisco IOS. If a review

of any claimed protocol defects shows that SSHv1 protocol in Cisco IOS is fundamentally broken, then Cisco

will determine if it is appropriate to migrate to SSHv2 at that time.

(5)

Testing Authentication

Testing Authentication Without SSH

We will test authentication without SSH first to make sure that authentication works with the router Carter

prior to adding SSH. Authentication can be with a local username/password or with an authentication,

authorization, and accounting (AAA) server running TACACS+ or RADIUS. (Authentication via the line

password is not possible with SSH.) The example below shows local authentication, which lets us Telnet into

the router with username "cisco" and password "cisco".

!−−− aaa new−model causes the local username/password on the router !−−− to be used in the absence of other aaa statements.

aaa new−model

username cisco password 0 cisco line vty 0 4

!−−− Instead of aaa new−model, the login local command may be used.

Testing Authentication With SSH

To test authentication with SSH, we add to the previous statements, enabling SSH on Carter and testing SSH

from the PC and UNIX stations.

ip domain−name rtp.cisco.com cry key generate rsa

ip ssh time−out 60

(6)

ip ssh authentication−retries 2

At this point, the show cry key mypubkey rsa command should show the generated key. After adding the

SSH configuration, we test accessing the router from the PC and Unix station; if this does not work, refer to

the debug section.

Optional Configuration Settings

Preventing Non−SSH Connections

If we want to prevent non−SSH connections, we add transport input ssh under the lines to limit the router to

SSH connections only. Straight (non−SSH) Telnets will be refused.

line vty 0 4

!−−− Prevent non−SSH telnets.

transport input ssh

We test to be sure non−SSH users cannot Telnet to the router Carter.

Setting Up an IOS Router as SSH Client

If we want to have one router act as an SSH client to the other, we can add SSH to a second router, Reed. The

routers will then be in a client−server arrangement, with Carter acting as the server and Reed acting as the

client. The IOS SSH client configuration on Reed is the same as required for the SSH server configuration on

Carter.

!−−− aaa new−model causes the local username/password on the router !−−− to be used in the absence of other aaa statements.

aaa new−model

username cisco password 0 cisco ip domain−name rtp.cisco.com cry key generate rsa

ip ssh time−out 60

ip ssh authentication−retries 2 line vty 0 4

!−−− Instead of aaa new−model, the login local command may be used.

To test this, issue the following command to SSH from the IOS SSH client (Reed) to the IOS SSH server

(Carter):

ssh −l cisco −c 3des 10.13.1.99

Adding SSH Terminal−Line Access

If we need outbound SSH terminal−line authentication, we can configure and test SSH for outbound reverse

Telnets through Carter, which is acting as a comm−server to Philly.

ip ssh port 2001 rotary 1 line 1 16

(7)

no exec rotary 1 transport input ssh exec−timeout 0 0 modem In Out Stopbits 1

If Philly is attached to Carter's port 2, we would SSH to Philly through Carter from Reed with the following

command:

ssh −c 3des −p 2002 10.13.1.99

From Solaris, we would use the following command:

ssh −c 3des −p 2002 −x −v 10.13.1.99

debug

and

show

Commands

Before issuing the debug commands described and illustrated below, please see Important Information on

Debug Commands.

debug ip ssh − Displays debug messages for SSH.

• show ssh − Displays the status of SSH server connections.

•

carter#show ssh

Connection Version Encryption State Username 0 1.5 DES Session started cisco

show ip ssh − Displays the version and configuration data for SSH.

•

carter#sho ip ssh

SSH Enabled − version 1.5

Authentication timeout: 60 secs; Authentication retries: 2

Sample Debug Output

Note that some of this "good" debug output has been wrapped to multiple lines because of spacing

considerations.

Router Debug

00:23:20: SSH0: starting SSH control process

00:23:20: SSH0: sent protocol version id SSH−1.5−Cisco−1.25 00:23:20: SSH0: protocol version id is − SSH−1.5−1.2.26 00:23:20: SSH0: SSH_SMSG_PUBLIC_KEY msg

00:23:21: SSH0: SSH_CMSG_SESSION_KEY msg − length 112, type 0x03 00:23:21: SSH: RSA decrypt started

00:23:21: SSH: RSA decrypt finished 00:23:21: SSH: RSA decrypt started 00:23:21: SSH: RSA decrypt finished

(8)

00:23:21: SSH0: sending encryption confirmation 00:23:21: SSH0: keys exchanged and encryption on 00:23:21: SSH0: SSH_CMSG_USER message received

00:23:21: SSH0: authentication request for userid cisco 00:23:21: SSH0: SSH_SMSG_FAILURE message sent

00:23:23: SSH0: SSH_CMSG_AUTH_PASSWORD message received 00:23:23: SSH0: authentication successful for cisco 00:23:23: SSH0: requesting TTY

00:23:23: SSH0: setting TTY − requested: length 24, width 80; set: length 24, width 80

00:23:23: SSH0: invalid request − 0x22

00:23:23: SSH0: SSH_CMSG_EXEC_SHELL message received 00:23:23: SSH0: starting shell for vty

Server Debug

Note: This output was captured on a Solaris machine.

rtp−evergreen.rtp.cisco.com# ssh −c 3des −l cisco −v 10.31.1.99 rtp−evergreen# /opt/CISssh/bin/ssh −c 3des −l cisco −v 10.13.1.99 SSH Version 1.2.26 [sparc−sun−solaris2.5.1], protocol version 1.5. Compiled with RSAREF.

rtp−evergreen: Reading configuration data /opt/CISssh/etc/ssh_config rtp−evergreen: ssh_connect: getuid 0 geteuid 0 anon 0

rtp−evergreen: Allocated local port 1023.

rtp−evergreen: Connecting to 10.13.1.99 port 22. rtp−evergreen: Connection established.

rtp−evergreen: Remote protocol version 1.5, remote software version Cisco−1.25 rtp−evergreen: Waiting for server public key.

rtp−evergreen: Received server public key (768 bits) and host key (512 bits). rtp−evergreen: Host '10.13.1.99' is known and matches the host key.

rtp−evergreen: Initializing random; seed file //.ssh/random_seed rtp−evergreen: Encryption type: 3des

rtp−evergreen: Sent encrypted session key.

rtp−evergreen: Installing crc compensation attack detector. rtp−evergreen: Received encrypted confirmation.

rtp−evergreen: Doing password authentication. [email protected]'s password:

rtp−evergreen: Requesting pty.

rtp−evergreen: Failed to get local xauth data.

rtp−evergreen: Requesting X11 forwarding with authentication spoofing. Warning: Remote host denied X11 forwarding, perhaps xauth program could not be run on the server side.

rtp−evergreen: Requesting shell.

rtp−evergreen: Entering interactive session.

What Can Go Wrong

Below is sample debug output from several incorrect configurations.

SSH from an SSH client not compiled with Data Encryption Standard

(DES)

Solaris Debug

(9)

SSH Version 1.2.26 [sparc−sun−solaris2.5.1], protocol version 1.5. Compiled with RSAREF.

rtp−evergreen: Reading configuration data /opt/CISssh/etc/ssh_config rtp−evergreen: ssh_connect: getuid 0 geteuid 0 anon 0

rtp−evergreen: Allocated local port 1023.

rtp−evergreen: Connecting to 10.13.1.99 port 22. rtp−evergreen: Connection established.

rtp−evergreen: Remote protocol version 1.5, remote software version Cisco−1.25 rtp−evergreen: Waiting for server public key.

rtp−evergreen: Received server public key (768 bits) and host key (512 bits). rtp−evergreen: Host '10.13.1.99' is known and matches the host key.

rtp−evergreen: Initializing random; seed file //.ssh/random_seed rtp−evergreen: Encryption type: des

rtp−evergreen: Sent encrypted session key. cipher_set_key: unknown cipher: 2

Router Debug

00:24:41: SSH0: Session terminated normally 00:24:55: SSH0: starting SSH control process

00:24:56: SSH0: sending encryption confirmation 00:24:56: SSH0: Session disconnected − error 0x07

Bad Password

Router Debug

00:26:52: SSH0: sending encryption confirmation 00:26:52: SSH0: keys exchanged and encryption on 00:26:52: SSH0: SSH_CMSG_USER message received

00:26:52: SSH0: authentication request for userid cisco 00:26:52: SSH0: SSH_SMSG_FAILURE message sent

00:26:54: SSH0: SSH_CMSG_AUTH_PASSWORD message received 00:26:54: SSH0: password authentication failed for cisco 00:26:54: SSH0: SSH_SMSG_FAILURE message sent

00:26:54: SSH0: authentication failed for cisco (code=7) 00:26:54: SSH0: Session disconnected − error 0x07

SSH client sends unsupported (blowfish) cipher

Router Debug

(10)

00:39:26: SSH0: sent protocol version id SSH−1.5−Cisco−1.25 00:39:26: SSH0: protocol version id is − SSH−1.5−W1.0 00:39:26: SSH0: SSH_SMSG_PUBLIC_KEY msg

00:39:26: SSH0: SSH_CMSG_SESSION_KEY msg − length 112, type 0x03 00:39:26: SSH0: Session disconnected − error 0x20

Cisco Configuring Secure Shell (SSH) on Cisco IOS Router

Table of Contents

Configuring Secure Shell (SSH) on Cisco IOS® Routers...1

Contents...1

Introduction...1

Hardware and Software Versions...1

SSHv1 vs. SSHv2...2

Network Diagram...2

Testing Authentication...3

Testing Authentication Without SSH...3

Testing Authentication With SSH...3

Optional Configuration Settings...4

Preventing Non−SSH Connections...4

Setting Up an IOS Router as SSH Client...4

Adding SSH Terminal−Line Access...4

debug and show Commands...5

Sample Debug Output...5

Router Debug...5

Server Debug...6

What Can Go Wrong...6

SSH from an SSH client not compiled with Data Encryption Standard (DES)...6

Bad Password...7

SSH client sends unsupported (blowfish) cipher...7

Tools Information...8

Related Information...8