Telnet and SSH Login Sequences: Notes and Examples
When you add a VNE, Prime Network uses the specified communication protocol to connect to the network element and gather modeling and status information. You must provide the information Prime Network will need: the characters and order of the network element’s expected prompts, and the string Prime Network should send to the network element in response (so that you can get to enable mode for Cisco IOS and Cisco IOS XE devices, and XML mode for Cisco IOS XR devices).
Before creating the login sequences, check for device-specific prerequisites and other details in Configuring Devices.
Note VNEs can understand partial and complete device prompts.
After an SSH session is established between the VNE and the device, the VNE starts the SSH login sequence. This sequence is usually shorter than the corresponding Telnet login sequence.
This topic provides two examples (with complete procedures) that show how to enter Telnet sequences:
A Telnet sequence (the order of the commands) must end with a line that includes only the enable prompt (for Cisco IOS and Cisco IOS XE devices) or the router CLI prompt (for Cisco IOS XR devices). Not all device families will have the same Telnet sequence; this is especially true for Cisco IOS devices. For RAD ACE-2300 devices, because SNMP is used for device modeling, we recommend disabling Telnet to avoid unnecessary queries.
Telnet Login Sequence for a Cisco IOS Device: Example
This sample procedure describes how you could enter a Telnet sequence for a hypothetical Cisco IOS device or Cisco IOS XE device.
Step 1 Check the
Enable
check box to activate the Telnet prompt fields.
Step 2 Enter the expected device prompt and response:
Note To verify a device’s Telnet sequence, open a Telnet session to the device and copy the information. The following is an example.
a. Enter
Password:
in the Prompt field.
Note If you do not want the password displayed in clear text, check Mask.
b. Enter
Rivers39*
in the Run field.
c. Click
Add
.
Step 3 Enter the device prompt and the command required to place the device in enable mode:
a. Enter
R3745>
in the Prompt field.
b. Enter
enable
in the Run field.
c. Click
Add
.
Step 4 Enter the enable mode password information:
a. Enter
Password:
in the Prompt field.
Note If you do not want the password displayed in clear text, check Mask.
b. Enter
!Tribal41_
in the Run field.
c. Click
Add
.
Step 5 Enter the enable prompt information:
a. Enter
R3745#
in the Prompt field.
Note VNEs can also understand partial prompts. For example, if you enter the string # instead of R3745#, the VNE will still be able to recognize the expected prompt.
Leave the Run field blank.
b. Click
Add
.
Telnet Sequence for a Cisco IOS XR Device: Example
This sample procedure describes how you could enter a Telnet sequence for a hypothetical Cisco IOS XR device.
Step 1 Check the
Enable
check box to activate the Telnet prompt fields.
Step 2 Enter the expected device prompt and response:
Note To verify a device’s Telnet sequence, open a Telnet session to the device and copy the information. The following is an example.
a. Enter
Username:
in the Prompt field.
b. Enter
crs1-oak
in the Run field.
c. Click
Add
.
Step 3 Enter the device password information:
Note Enter Password: in the Prompt field.
Note If you do not want the password displayed in clear text, check Mask.
d. Enter
sunFlower108!
in the Run field.
e. Click
Add
.
Step 4 Enter the device prompt:
a. Enter
EC-A#
in the Prompt field.
Note For devices with multiple processors (such as Cisco CRS), the prompt comprises the active CPU plus the device name (for example, RP/0/RSP0/CPU0:EC-A#). A CPU failover could change the prompt and report a different CPU. In these cases, you should insert a prompt that specifies only the device name (for example, EC-A#). (Also, as with Cisco IOS, VNEs can also understand partial prompts. For example, if you enter the string # instead of EC-A#, the VNE will still be able to recognize the expected prompt.)
Leave the Run field blank.
b. Click
Add
.
Notes on SSHv2 Public Key and Private Key File Formats
There are several file formats for public and private RSA and DSA keys. The same key can be written differently according to the format that is used.
This application officially supports the openSSH format. For more details, see
http://www.openssh.com/manual.html
.
Make sure that the keys you provide as input parameters are in this format. If they are not, you need to convert them to the open SSH format before applying them.
Use Case Example: When working with Cisco IOS, the public key is retrieved using the
show crypto key mypubkey
command. This format is not compatible with the OpenSSH format, and is not supported. There are several ways to convert the format.
The easiest solution is to use public key scan by the (free) openSSH application to retrieve the public key in the supported format. For more details, see
http://www.openssh.com/manual.html
.
Another option is to convert the files to the required format either manually or by using a script.
The following are examples of valid file formats.
-----BEGIN RSA PRIVATE KEY----- MIICWwIBAAKBgQDvdpW8ItfbSp/hTbWZJqCPmjRyh9S+EpTJ0Aq3fnGpFPTR+ TiOfhiuX5+M1cTaE/if8sScj6jE9A0MpShBrnDU/0A== -----END RSA PRIVATE KEY----- -----BEGIN DSA PRIVATE KEY----- MIIBuwIBAAKBgQDNGO+l2XW+W+YtVnWSYbKXr6qkrH9nOl+ -----END DSA PRIVATE KEY----- ssh-dss AAAAB3………HfuNYu+ DdGY7njEYrN++iWs= aslehr@aslehr-wxp01 ssh-rsa AAAAB3…lot more…qc8Hc= aslehr@aslehr-wxp01