Thursday, January 5, 2017

The best way to Configure SSH (Secure Shell) for Distant Login on a Cisco Router

Prior to the introduction of SSH in the Cisco IOS, the only distant login protocol was Telnet. Though fairly useful, Telnet is a non-secure protocol through which the entire session, including authentication, is in clear text and thus subject to snooping.

SSH is each a protocol and an software that replaces Telnet and supplies an encrypted connection for remote administration of a Cisco community gadget resembling a router, swap, or safety appliance.

The Cisco IOS contains both an SSH server and an SSH consumer. This doc is concerned only with the configuration of the SSH server part.


Software program

The SSH server part requires that you've an IPSec (DES or 3DES) encryption software program image from Cisco IOS Release 12.1(1)T or later installed in your router. Superior IP companies pictures include the IPSec element. This document was written utilizing c2800nm-advipservicesk9-mz.123-14.T5.bin.


It's essential to configure a hostname and a site title in your router. For example:


router#conf t

Enter configuration instructions, one per line. End with CNTL/Z.

router01(config)#hostname router01

router01(config)#ip area-title soundtraining.web

You should also generate an RSA keypair on your router which routinely allows SSH. Within the following instance, observe how the keypair is known as for the mix of hostname and domain name that have been beforehand configured. The modulus represents the key size. Cisco recommends a minimal key length of 1024 bits (though the default key length is 512 bits):


router01(config)#crypto key generate rsa

The name for the keys will probably be: router01.soundtraining.web

Select the dimensions of the key modulus in the range of 360 to 2048 in your Normal Objective Keys. Selecting a key modulus larger than 512 might take a couple of minutes.

How many bits within the modulus [512]: 1024

% Producing 1024 bit RSA keys ...[OK]

Lastly, you need to either use an AAA server resembling a RADIUS or TACACS+ server or create a neighborhood person database to authenticate remote customers and enable authentication on the terminal traces. For the purpose of this doc, we'll create a local consumer database on the router. Within the following example, the person "donc" was created with a privilege degree of 15 (the utmost allowed) and given an encrypted password of "p@ss5678". (The command "secret" adopted by "zero" tells the router to encrypt the next plaintext password. In the router's running configuration, the password would not be human readable.) We also used line configuration mode to tell the router to use its local user database for authentication (login local) on terminals lines 0-4.

router01(config)#username donc privilege 15 secret zero p@ss5678

router01(config)#line vty 0 four

router01(config-line)#login native

Enabling SSH

To allow SSH, you could tell the router which keypair to make use of. Optionally, you can configure the SSH version (it defaults to SSH version 1), authentication timeout values, and a number of other different parameters. Within the following instance, we instructed the router to make use of the previously created keypair and to use SSH version 2:


router01(config)#ip ssh model 2

router01(config)#ip ssh rsa keypair-identify router01.soundtraining.internet

Now you can go browsing to your router securely using an SSH client corresponding to TeraTerm.

Viewing SSH Configurations and Connections

You can use the privileged mode instructions "view ssh" and "view ip ssh" to view SSH configurations and connections (if any). In the following instance, the SSHv1 configuration from a Cisco 871 router is verified utilizing "show ip ssh" and a single SSHv1 connection is displayed utilizing the command "show ssh". Discover that we did not enable SSHv2 on this router, so it defaulted to SSH model 1.99. Also observe within the output of the "present ssh" command that SSH model 1 defaults to 3DES. SSHv2 supports AES, a extra robust and environment friendly encryption expertise. SSHv2 can be not subject to the identical security exploits as S

No comments:

Post a Comment