StopUsingTelnet

8/9/2019 StopUsingTelnet

1/15

Stop Using Telnet!

Implementing SSHon Cisco Devices

1-800-COURSES www.globalknowledge.com

Expert R eference Series of White Papers


2/15

So,WhatsWrong with Telnet Anyway?All too commonly, the method for remote access to the CLI of Cisco devices is performedusing telnet and the method to "authenticate" 1 the administrator is a password assigned to theline which is known by all administrators. The chief problem with using telnet is all of the datacrosses the wire in clear text. This includes the authentication data: username, line password,and enable password. Anyone who is in a position to capture packets as they cross the net-work (including those without authorization or privilege but are using attack tools such as dsniffand ettercap) can capture the authentication credentials. Once they have the authenticationcredentials required, they can connect to the Cisco network devices, masquerading as a validsystem administrator.

As network security awareness increases, the use of telnet by network administrators is dimin-ishing. The goal of this paper is to provide the reader with an understanding of the SecureShell (SSH) protocol, so it can be deployed as a much more secure alternative to telnet. HowSSH functions, without getting bogged down in the mathematics of encryption, will be dis-cussed. Then configuration of SSH will be demonstrated for three popular Cisco platforms (IOSrouter and switch, Catalyst OS Switch, and PIX firewall).

Introduction to Encryption TechnologiesBefore addressing SSH directly, encryption must be addressed generally. There are two mainclassifications of encryption algorithms: Symmetric and Asymmetric.

Symmetric encryption algorithms depend on a shared key. That is, there is one algorithm thatuses the shared key to transform the original clear-text message into cipher text. This ciphertext is unreadable by anyone who does not know the shared key. There is a correspondingdecryption algorithm which, given the shared key, can transform the cipher text back into theoriginal clear-text message. Current revisions of Cisco products generally support three differ-ent encryption algorithms: DES (Data Encryption Standard), Triple DES (3DES), and AES(Advanced Encryption Standard). DES and 3DES have been available for a long time, whileAES support is relatively new. In general, the strength of a symmetric encryption algorithm isbased on its key size. An attacker must determine what the shared key is to decrypt theencrypted messages. The larger the key space, the more difficult it becomes to perform brute-force cracking. DES uses a 56-bit key. 3DES uses the DES algorithm three times, using differ-ent keys, resulting in the equivalent of a 168-bit key. AES supports multiple key sizes, including128 bit, 192 bit, and 256 bit. Note: the strength of the key does not increase linearly, but expo-

Kurt E. Patzer, Course Director and Inst ructor, Global Knowledge

Stop Using Telnet!Implementing SSH on Cisco Devices

Copyright 2004 Global Knowledge Net wor k, Inc. All ri ght s reserved. Page 2

1 The term authenti cate is in quotatio n marks because using a shared password does not trul y authenticate. Aut hentication is the process determini ng a unique ent itysiden tity. With a shared password you only know that the entity is a member of the group of entities who know the password, not the unique entity from that group.


3/15

nentially. That is, adding one bit to the key size doubles the key search space. Adding 64 bitsmultiplies the key space by a factor of more than 1.8x10 19 .

Asymmetric encryption algorithms use public/private key pairs. Data that is encrypted with theprivate key can be decrypted with the corresponding public key and only the correspondingpublic key. Data that is encrypted with the public key can be decrypted with the correspondingprivate key and only the corresponding private key. In practical use, the private key is keptcompletely private. It is known only to the entity that owns it. The public key, on the other hand,is freely distributed and assumed to be known by everyone (trusted and untrusted entities).Asymmetric encryption can be used in either direction. If entity A needs to send a private mes-sage to entity B, it can use entity Bs public key to encrypt the message. This can only bedecrypted by entity B using its private key. Untrusted entity C who also knows entity Bs publickey can not decrypt the message because entity Bs private key is what is required.Asymmetric encryption can be used in the other direction as well. Entity B can encrypt a mes-sage destined for entity A with entity Bs own private key. The value of this may not be obvious.The message can be decrypted by anyone, not just entity A. This is because it is assumed thatall entities have access to entity Bs public key. Hence, encrypting a message with a devices

own private key does not provide privacy. But, when entity A successfully decrypts the mes-sage sent by entity B, there are some things of which entity A can be assured: the messagecan successfully be decrypted with entity Bs public key; the message definitely originated fromentity B; and the message has not been altered in transit. Used in this way, public/private keypairs are the basis of digital signature technologies. The asymmetric encryption algorithm sup-ported by Cisco devices is RSA (Rivest, Shamir, Adelmanthe authors of the algorithm). Ciscodevices allow a configurable RSA key size between 360 and 2,048 bits.

Asymmetric encryption algorithms are much more computationally expensive to use than sym-metric algorithms. For this reason, bulk data transfers are always performed using symmetricalgorithms, but initial tunnel setup often depends on limited use of asymmetric algorithms.

How SSH WorksSSH is still undergoing some evolution. There are two distinct versions: SSH1 and SSH2.SSH2 is a completely rewritten protocol and is not backward compatible with SSH1 (althoughSSH servers often support both SSH1 and SSH2 protocols). Both SSH1 and SSH2 are docu-mented in IETF drafts. The expectation is for SSH2 to eventually reach RFC status, whileSSH1 development has stopped and hence will remain a draft. As of this writing, most Ciscodevices support SSH1 (version 1.5), but SSH2 support is starting to show up, including somesupport for the SCP and SFTP file transfer protocols defined under SSH2. This paper focuseson version 1.5 support for CLI access. The concepts and configuration methods should still bevalid as Cisco support migrates towards SSH2.

SSH uses encryption to protect all data sent across the wire, including login credentials, usinga symmetric encryption algorithm. This requires the use of a shared key between the SSHclient (the workstation used by the network administrator) and the SSH server (the Ciscodevice). Hard coding the shared key on the client and server would be impractical and relative-ly insecure (if the same key is always used, it may eventually be compromised and all furtherdata exchange could be intercepted by unauthorized entities). To alleviate this issue, asymmet-



4/15


5/15

Jul 22 15:00:17.850: SSH: RSA decrypt finishedJul 22 15:00:17.882: SSH0: sending encryption confirmationJul 22 15:00:17.886: SSH0: keys exchanged and encryption onThe username "admin" is entered.Jul 22 15:00:26.602: SSH0: SSH_CMSG_USER message receivedJul 22 15:00:26.602: SSH0: authentication request for

userid adminJul 22 15:00:26.606: SSH0: SSH_SMSG_FAILURE message sentThe password " adminpass" i s entered.Jul 22 15:00:32.118: SSH0: SSH_CMSG_AUTH_PASSWORD messagereceivedJul 22 15:00:32.186: SSH0: authentication successful forAdminAuthentication has succeeded. The terminal settings are exchanged and aVTY line is assigned for the connection.Jul 22 15:00:32.190: SSH0: requesting TTYJul 22 15:00:32.190: SSH0: setting TTY - requested: length24, width 80; set: length 24, width 80Jul 22 15:00:32.194: SSH0: SSH_CMSG_EXEC_SHELL messagereceivedJul 22 15:00:32.194: SSH0: starting shell for vtyThe remote user has access to the routers CLI. The exit command isused from the CLI to terminate the connection.Jul 22 15:00:36.230: SSH0: Session terminated

Basic SSH Configuration on IOS R outersThere are four steps to configure SSH on IOS routers:

1. Ensure that the IOS version and feature set supports SSH.2. Enable SSH.3. Optionally adjust the SSH authentication parameters.4. Optionally limit remote connections to only SSH (disabling telnet) and to limit whichIP addresses are trusted to source SSH connections.

For SSH support, both the IOS version and feature set are important. SSH is supported start-ing with version 12.1(1)T. You must also have a feature set which includes IPSec with DES orTriple DES encryption.

SSH support requires AAA authentication to be configured on the router. AAA stands forAuthentication, Authorization, and Accounting. Authentication determines who a user is.Authorization specifies what a user is allowed to do. Accounting tracks what a user has done.AAA for administrative access is most elegantly implemented with a TACACS+ server. Thisserver can provide a centralized location to manage user accounts for all of the Cisco devicesin your network. It can also manage command authorization for different administrators. Thegranularity of command authorization can be controlled down to per-user and per-device lev-els. The TACACS+ server can also track all commands entered by administrators across the

Copyright 2004 Global Knowl edge Netwo rk, Inc. All r ight s reserved. Page 5


6/15

Cisco devices, providing a powerful auditing capability. This type of AAA configuration goeswell beyond the scope of this white paper. To support SSH, authentication is the only AAAmethod required, and it is implemented most simply within the routers local configuration.

The aaa new-mode l command enables AAA on the router. Using the command causes thecommand login authentication default to be configured on each of the routers lines (CON,AUX, and VTY). The command does not appear in the running configuration because it is nowthe default. But you will notice the login command (without any arguments) that was requiredto support a login password is removed from the running configuration. To specify the use ofthe local configuration as the source of usernames and passwords, the command aaa authen-tication default local is used. To specify a username and password in the local configuration,the username x secret y command is used. Note: username x password y is also an option,but then the password either shows up in clear text or protected by a very simple encryptionalgorithm instead of the more secure MD5 hash, which is used for secret. The following tran-script shows the configuration of AAA, including the username admin with the passwordadminPass. Extraneous text has been removed and comments have been added in bold toimprove the transcripts clarity.

Configuration of simple AAA authentication using the local user database.router(config) # aaa new-modelrouter(config) # aaa authentication login default localrouter(config) # username admin secret adminpassrouter(config) # exitrouter # show run...enable secret 5 $1$uOqt$9gQ7T98F2HYUTT73YvfpR....username admin secret 5 $1$qbV9$DYmHZJPweXPMI7srxVsLs1aaa new-model

...aaa authentication login default localNote the command " login" no longer appears under any of the lines. Thenew default is "login authentication default" . The AAA method named"default" has been specified to use the usernames and passwords in therouters local database.line con 0

exec-timeout 0 0password cisco

line aux 0exec-timeout 0 0password cisco

line vty 0 4exec-timeout 0 0password cisco

After configuring AAA, the only requirement to enable SSH is to generate a pair of RSA keyson the router. This itself has the prerequisite of having both a hostname and a domain name



7/15

configured on the router. When generating RSA keys, the user can select a key size between360 and 2,048 bits. The greater the key size, the more secure the encryption is, but the morehorsepower required for key generation as well as subsequent encryption and decryption.Cisco recommends an RSA key size of at least 1,024 bits.

The following transcript shows the definition of a hostname and domain name and the genera-tion of an RSA public/private key pair. Note the message indicating that SSH is enabled whichthe router displays after generating the keys.

The definit ion o f the routers hostname and domain name are prerequi-sites for the generation of RSA key pairs.router(config) # hostname PerimGWPerimGW(config) # ip domain name sshwhitepaper.labA 1024 bit key pair is generated with the following command.PerimGW(config) # crypto key generate rsaThe name for the keys will be: PerimGW.sshwhitepaper.labChoose the size of the key modulus in the range of 360 to2048 for your General Purpose Keys. Choosing a key modulusgreater than 512 may take a few minutes.

How many bits in the modulus [512]: 1024% Generating 1024 bit RSA keys ...[OK]

Note the message stating that SSH is now enabled.Jul 21 16:49:53.708: %SSH-5-ENABLED: SSH 1.5 has beenenabled

After only six commands (three to enable AAA and three to enable SSH), SSH is now enabledon the router. The next thing that should be done is to disable insecure connection protocols. Adefault command that is assigned to the VTY lines is transport input all. This allows all support-ed connection protocols, including IP-based, clear-text protocols such as telnet and rlogin, aswell legacy protocols such as NASI and ARAP. The goal is to allow only SSH, so the commandtransport input ssh should be applied to the VTY lines. This will allow SSH and disallow allother connection protocols. Optionally, connections can be restricted to a few trusted-source IPaddresses. This is done the same way that it would be done for telnet connectivity. That is, toapply an access control list (ACL) to the VTY lines using the access class command.

There are just a few more options available to tweak the basic behavior of the SSH server onthe router. A session inactivity timer can be configured which will disconnect SSH sessionsafter a period of idleness. This is done with the exec timeout command, just as it is done fortelnet. The default exec timeout is 10 minutes. There is also the ip ssh timeout command.This timer controls how long the router waits for user authentication to complete before ittimes-out the connection. The maximum and default are both 120 seconds. And there is the ipssh authentication-retries command, which specifies how many chances the user gets toenter a valid username/password combination before they are disconnected. The default isthree and the maximum is five. The following transcript shows the configuration of these SSHsettings on a Cisco IOS router.

Copyright 2004 Global Knowledge Netw ork, Inc. All r ight s reserved. Page 7


8/15

Access-list 10 defines the two trusted hosts and one trusted subnet fromwhich SSH connections can be made.PerimGW(config) # access-list 10 permit 10.10.10.101PerimGW(config) # access-list 10 permit 10.10.10.102PerimGW(config) # access-li st 10 permit 10.10.200.0 0.0.0.255The VTY lines are configured to enforce ACL 10, only allow SSH, and havean inactivity timeout of 5.5 minutes.PerimGW(config) # line vty 0 4PerimGW(config-line) # access-class 10 inPerimGW(config-line) # transport input sshPerimGW(config-line) # exec-timeout 5 30PerimGW(config-line) # exitThere are also optional settings fo r the SSH authentication timeout andmaximum authentication retries.PerimGW(config) #ip ssh time-out 60PerimGW(config) #ip ssh authentication-retries 2

Using SSH ClientsThe biggest drawback to using SSH for Cisco CLI access is that an SSH client is not includedin a standard Windows installation. There are several commercially available SSH clients forWindows platforms, but there is also a pair of well-respected, freely-distributable clients. Thefirst is PuTTY (http://www.chiark.greenend.org.uk/~sgtatham/putty/) and the second is TeraTerm (http://hp.vector.co.jp/authors/VA002416/teraterm.html). SSH is included in several stan-dard UNIX distributions and is also available from the OpenSSH website(http://www.openssh.com). There is a freely-distributable Macintosh SSH client named Nifty.Even an IOS router, with an IPSec feature set at or above version 12.2(2)T supports ssh clientfunctionality.

The download and installation of either PuTTY or Tera Term is straightforward and will not bediscussed here. The main purposes of this section are to demonstrate client connection to therouter configured in the previous sections, to show how SSH clients manage the public keys ofdifferent servers, and to explain how to prevent connecting to an invalid SSH server mas-querading as the valid SSH server.

As described earlier, when an SSH client connects to an SSH server, the server presents theclient with its public key. Since, for practical purposes, the public key is unique and only workswith the private key owned by the server, it can be used as an ad hoc form of authentication. Ifa server presents the expected public key, and it can decrypt the proposed session keyencrypted with this public key, then it must be the correct server. That is, it is not anotherdevice masquerading as the server and attempting a man-in-the-middle-attack. For this rea-son, you should verify that the public key presented is the correct one. SSH clients help withthis effort. When an SSH client connects to an SSH server for the first time, the client will dis-play a fingerprint of the public key. You must verify the authenticity of this fingerprint. After youaccept the fingerprint, the SSH client stores the key for this server. For all future connections, ifthe public key presented by the server is the same as the one that is stored by the SSH client,



9/15

the connection is established without further verification on your part. If, however, the serverpresents a different key, the SSH client will warn you that the key has changed. Either theserver has had its public/private key pair changed for a valid reason, or an entity is attemptinga man-in-the-middle attack.

The challenge is that SSH clients present a fingerprint of the public key for verification, insteadof the whole key. In some ways this is an advantage as the fingerprint is a smaller size, andtherefore easier to scan. The problem is that different SSH clients use different finger printalgorithms, so there is no way of viewing the public key on an IOS router and predicting whatdifferent SSH clients will display as the fingerprint. The transcript below shows the display of apublic key on a router. Figure 1 shows the fingerprint of this key displayed by PuTTY. Figure 2shows the fingerprint of this key displayed by SSH Communications Security CorporationsSSH client.

The router will display its public key with the show crypto key mypubkeyrsa command, but there is no way to display its private key.PerimGW #show crypto key mypubkey rsa% Key pair was generated at: 16:49:52 UTC Jul 21 2004Key name: PerimGW.sshwhitepaper.lab

Usage: General Purpose KeyKey is not exportable.Key Data:

30819F30 0D06092A 864886F7 0D010101 05000381 8D00308189028181 00A7B4DD

6C535544 90414487 487A4D97 9C1F041E 3B884706 9D4CF9A41A33CCA9 B4A7EF72

6F1CD870 D22FE643 86590799 2AA50E91 27A69B45 1C8C6853CB7B43CE 9A915BB1

1DEB043D 49509DB9 7B5AEC11 2706D78F C872441E 0ECA75AB

899A1B17 A08A14A3221171B1 8731F8E1 6EAD23AF 4DFC4F8E 60633CB8 A7D2BC1F

B84004FA E5020301 0001% Key pair was generated at: 16:49:58 UTC Jul 21 2004Key name: PerimGW.sshwhitepaper.lab.server

Usage: Encryption KeyKey is exportable.Key Data:

307C300D 06092A86 4886F70D 01010105 00036B00 3068026100B58DC1 A4F267DC

54DD8257 62589D39 47C2CB43 9D91864F 0257DAD5 B95D64E175380A20 A3E61793

97CEEFF4 6CA014AF DA5CA8AF 9F15B654 035ED495 5AB2B53F9CC53BF3 E4F30EF9

F9F7CA73 836C468E 3D443CDD 5F067D05 29A742BD E0C03F006B020301 0001

One strategy to deal with the unpredictability of how SSH clients compute public key finger-

Copyright 2004 Global Knowl edge Netwo rk, Inc. All ri ght s reserved. Page 9


10/15

prints is to settle on a standard SSH client for your organization. Then when you set up SSHservices on a new device, connect to that device using the standard client. Verify that you areconnected to the correct device. For example, with an IOS router, the show users commandwill display current VTY connections, including the source IP address. Make sure the routersees the connection coming from your current IP address. When you are certain that you are


Figure 1: Fingerprint displayed by the PuTTY client upon initial SSH connection to an SSH server.

Figure 2: Fingerprint displayed by SSH Communications Security Corporations SSH client upon initial connection toan SSH server.


11/15

connected to the correct device, record the fingerprint displayed by your organizations stan-dard SSH client. This fingerprint can then be published so your organizations staff can verifythe reported fingerprints against the documented valid fingerprints.

Figure 3 shows an example of a warning from the PuTTY client when it is presented with apublic key other than the one that was validated by the user. Warnings like this should beheeded. Sometimes the public/private key pairs on a device do change for valid reasons. But ifthe keys have not changed, the connection should not be allowed and the potential man-in-the-middle attack should be investigated.

Configuring SSH on IOS SwitchesConfiguration of the SSH server on IOS switches follows the same syntax as that described forrouters. The only issue is whether SSH is supported on the switch model or not. Unfortunately,the following models do not support SSH: Catalyst 1900; Catalyst 2800; Catalyst 2948G_L3;Catalyst 2900XL; Catalyst 3500XL; C Catalyst at 4840G_L3; and Catalyst 4908G_L3. The fol-lowing IOS switches do support an SSH server, given a minimum operating system version: Cat2950: 12.1(12c)EA1 and higher; Cat 3550: 12.1(11)EA1 and higher; Cat 4000/4500 (IntegratedIOS): 12.1(13)EW and higher; and Cat 6000/5500 (Integrated IOS): 12.1(11b)E and higher.

Copyright 2004 Global Knowledge Netw ork, Inc. All right s reserved. Page 11

Figure 3: Warning of a potential man-in-the-middle attack attempt by the PuTTY client when presented with a differ-ent public key from a known SSH server.


12/15

Configuring SSH on Catalyst Operating System SwitchesBefore configuring SSH on a Catalyst OS device, you must be sure that the operating systeminstalled on the device supports SSH. SSH support of all images that support 3DES became avail-able in version 6.1. 3DES support in the image is indicated if "k9" appears in the image name.

Configuring SSH on a Catalyst OS is simpler than on an IOS device. For example, configuringAAA is not required. Generation of an RSA public/private key pair is initiated with the set cryp-to key rsa keysize command. The set ip permit command is used to control which IPaddresses are trusted as the source of telnet connections, SSH connections, and SNMPrequests. The set ip permit command should be enabled for both telnet and SSH, but only theSSH permit table should be populated with entries. This will, in effect, disable telnet support.The following transcript displays the configuration of SSH on a Catalyst OS switch.

An RSA public/private key pair is generated.sw1-1> (enable) set crypto key rsa 1024Generating RSA keys.......... [OK]Three entries are added to an SSH permit list. Note that no entries areadded for the telnet permit lis t.sw1-1> (enable) set ip permit 10.10.1.0 255.255.255.0 ssh10.10.1.0 with mask 255.255.255.0 added to Ssh permitlist.sw1-1> (enable) set ip permit 10.10.2.10 255.255.255.255 ssh10.10.2.10 with mask 255.255.255.255 added to Ssh permitlist.sw1-1> (enable) set ip permit 10.10.2.20 255.255.255.255 ssh10.10.2.20 with mask 255.255.255.255 added to Ssh permitlist.The SSH and telnet permit lists are enabled (but the telnet permit list is

empty)sw1-1> (enable) set ip permit enable sshSSH permit list enabled.sw1-1> (enable) set ip permit enable telnetTELNET permit list enabled.View the current permit settings.sw1-1> (enable) show ip permit

Telnet permit list enabled.Ssh permit list enabled.Snmp permit list disabled.

Permit List Mask Access-Type---------------- ---------------- -------------10.10.1.0 255.255.255.0 ssh10.10.2.10 ssh10.10.2.20 ssh

Denied IP Address Last Accessed Time Type----------------- ------------------ ------



13/15

Configuring SSH on PIX FirewallsConfiguration of SSH is also relatively straightforward on a PIX firewall. The use of any encryp-tion technology requires that a DES or a 3DES/AES activation key has been entered into thePIX. The hostname and domain name must be configured prior to generating the RSApublic/private key pair. The key pair is generated using the ca generate rsa key key_size

command, and saved using the ca save al l command. Once the key pair is generated, SSH isenabled simply by defining the IP addresses trusted to source SSH connections with the sship_address [netmask] command. AAA does not have to be enabled. When AAA is notenabled, the PIX accepts "pix" as a default username, and "cisco" as the default password.Obviously the default password must be changed to have any sense of security. It is changedwith the passwd command. As on a router, AAA services can be enabled for a more elegantauthentication service. The following transcript shows the configuration of SSH support on aPIX firewall.

Configuring a hostname and domain name is a prerequisite to the creationof a publ ic/private key pair.pixfirewall(config) # hostname wppixwppix(config) # domain-name sshwhitepaper.labwppix(config) # ca generate rsa key 1024For >= 1024, key generation could

take up to several minutes. Please wait.Keypair generation process begin..Success.wppix(config) # ca save allSSH connection are only allowed from addresses defined using the sshcommand.wppix(config) # ssh 10.10.10.101wppix(config) # ssh 10.10.200.0 255.255.255.0

wppix(config) # ssh 10.10.8.10There is a default username "pix" with a default password of "ci sco" . Thisdefault password MUST be changed wi th the passwd command.wppix(config) # passwd p1XpasswordSet the SSH session idle timeout to fi ve minutes.wppix(config) # ssh timeout 5

"R everse-SSH" FunctionalityA more advanced use of SSH is to replace telnet in reverse-telnet configurations. Reverse-tel-net is often used to provide a more robust remote network management capability than canexist with standard telnet connections. A specially configured Cisco router is generally used forthis and is called either an access server, a comm. server or a terminal server. The router isconfigured with an async module with lines directly connected to the console ports of otherdevices in the same wiring facility. By establishing a telnet session to this access server andconnecting through one of the async lines (i.e. reverse telnet), remote connectivity directly to adevices console port is possible. This allows strong remote management capabilities such asviewing the devices power on self-test messages during boot, or communicating with a device



14/15

which is stuck in ROMMON mode. Since the same concerns about telnet exist for access serv-er communication as exist for standard telnet command line access, SSH should be used inthis situation as well. The ip ssh port command was introduced in 12.2(2)T, which allows forthe use of SSH instead of telnet for this type of configuration. Using an SSH based comm.server not only allows network-based access to the console port of a device, but it also offersan ability to have an encrypted connection to a device which doesnt support SSH. For exam-ple, a 2900XL series switch does not support SSH. If a 2900XLs console port is connected toa line on a comm. server which does support SSH, you can reach the 2900XLs CLI via thismethod instead of an insecure telnet connection.

The following transcript shows the configuration of a comm. server with 16 async lines for SSHsupport.

wpCommSrv(config)#ip ssh port 2001 rotary 1wpCommSrv(config)#line 1 16wpCommSrv(config-line)#no execwpCommSrv(config-line)#rotary 1wpCommSrv(config-line)#transport input sshwpCommSrv(config-line)#exec_timeout 0 0wpCommSrv(config-line)#modem In OutwpCommSrv(config-line)#Stopbits 1

To establish a connection to the device whos console is connected to line 1 requires establish-ing an SSH session to port 2001. To connect to the device whose console port is connected toline 2 requires establishing an SSH session to port 2002. Most SSH clients allow you to speci-fy the destination TCP port for the connection. If the SSH client does not allow configuring adestination port other than the default of TCP port 22, you can still connect to the comm. serv-er itself via SSH, and then initiate a new connection from it. If its IP address is 10.10.10.101,the syntax of the command would be ssh c 3des p 2001 10.10.10.101 .

ConclusionYou should now have a good understanding of how SSH works, and why it should be config-ured and used in place of telnet wherever possible. SSH does have some vulnerability to aman-in-the-middle attack when a client connects to a server for the first time. Documentingexpected fingerprints, and validating the fingerprint on the initial connection can mitigate this. Ifthis is done, SSH provides origin authentication and privacy. Telnet can provide neither ofthese features. As security consciousness increases, the use of SSH should increase over tel-net. SSH should be configured to replace telnet on any device that supports SSH. Deviceswhich do not support SSH directly can still gain the advantage of SSH via a communicationsserver which does support SSH.

Learn MoreLearn more about how you can improve productivity, enhance efficiency, and sharpen yourcompetitive edge. Check out the following Global Knowledge courses:Interconnecting Cisco Network Devices



15/15

Building Scalable Cisco InternetworksSecuring Cisco IOS NetworksCisco Secure PIX Firewall AdvancedBuilding Cisco Remote Access Networks

For more information or to register, visit www.globalknowledge.com or call 1-800-COURSES tospeak with a sales representative.

Our courses and enhanced, hands-on labs offer practical skills and tips that you can immedi-ately put to use. Our expert instructors draw upon their experiences to help you understandkey concepts and how to apply them to your specific work situation. Choose from our morethan 700 courses, delivered through Classrooms, e-Learning and On-site sessions, to meetyour IT and professional skills training needs.

About the AuthorKurt Patzer has over a decades experience in networking. He spent eight years working forIBMs networking software laboratory in Research Triangle Park, NC where he specialized innetwork implementation and management. Since 2000, he has worked as an instructor forGlobal Knowledge and as an independent consultant. He is currently the course director forthe CiscoWorks course (CWENT) and co-course director for the CCSP curriculum (SECUR,CSPFA, CSVPN, CSIDS, and CCSP Boot Camp). He holds an MS in Computer Science andCCSP, CCNP, and CCSI certifications. Kurt may be reached at [email protected].

R esourcesThe SSH (Secure Shell) Remote Login Protocol . Internet-Draft. Helsinki University of

Technology. November 15, 1995.

The SSH FAQ . http://www.openssh.com/faq.html, April 12, 2004.

Configuring Secure Shell on Routers and Switches Running Cisco IOS . Cisco Systems, Inc.www.cisco.com, Document ID 4145. Copyright 1992-2003

Cisco PIX Firewall and VPN Configuration Guide . Version 6.3. Cisco Systems, Inc.Copyright 1992-2004.

How to Configure SSH on Catalyst Switches Running CatOS . www.cisco.com, Document ID13881. Copyright 1992-2003.


Documents

StopUsingTelnet