Successive SSH Sessions from Console

[CiscoKid08]

Hello,

I'm using SecureCRT to execute a number show commands against a series of Cisco switches.

For some network segments, we need to SSH to a specific switch (to use as a jumphost) to gain access to compartmentalized network segments.

So I'll start the session by SSHing to Switch1 then from there SSH to Switch2. From Switch2, I'll SSH to all of the child switches and run my show commands.

Using SecureCRT, I can do this manually pretty easily. For example, once I'm on Switch2, I can run the following:

ssh -l admin 10.0.0.1
password
terminal length 0
show run
show logging
exit

ssh -l admin 10.0.0.2
password
terminal length 0
show run
show logging
exit

ssh -l admin 10.0.0.3
password
terminal length 0
show run
show logging
exit

Entering these commands line by line works perfectly and I'm able to capture all the output needed. However when I attempt to enter these all in one batch (using copy-paste), it seems I get through to the first switch but the "exit" command will prevent SecureCRT from entering in any of the subsequent lines to initiate additional SSH sessions. I would have assumed that a copy-paste of the above is all that's needed to hit all three switches but that appears to not be the case. Is there something I'm missing? The "exit" command will successfully quit the first SSH session (.1 in the example) but no SSH connections are initiated to .2 or .3.

Does anyone have any suggestion or feedback on this? It seems I've overlooked something.

[cboyack]

Hi CiscoKid08,

In your situation, what is most likely occurring is that all of the commands you've copied to the clipboard are being sent to your first child switch (.1 in your example). The unexecuted commands are all queued up there, but once the exit command is sent to the child switch, the rest of the commands that were sent to that switch are dropped by child switch 1, which is why you get the output from the first switch while the rest of the connections are not initiated.

There are a couple of ways you could deal with this situation to make automation easier. Neither of these options works in all situations, but they may work in your case.

Possible Solution #1:
If, and only if, the shell prompt for your Switch2 and all of your child switches ends with a "#" (or the exact same character, be it %, >, etc.), you can set SecureCRT (during an operation in which multiple lines are being sent) to wait to send subsequent lines until SecureCRT receives a specific prompt sequence, which in this case would be "#". Making this change should allow SecureCRT to wait for the prompt before sending further lines of text.

To make this change, navigate to Session Options > Terminal > Emulation > Advanced, enable the "Prompt:" option, and set the prompt field to "#". Keep the "Max wait (ms):" set to 0, so SecureCRT will wait as long as it needs to for the prompt to be received before sending the next line of text.

Possible Solution #2:
If the above option doesn't work in your situation (for example, if the shell prompts don't have common character endings), you may, instead, set the "Line send delay:" option in the same Advanced category to a larger number of milliseconds (the exact number you'd require depends on your connection and the speed with which the commands are processed). This will, in effect, tell SecureCRT to wait a specified amount of time between sending each line of text.

Note: The value you specify for the "Line send delay:" must be greater than or equal to the maximum time required for the slowest command to complete. For example, you have show run and show logging commands listed, which may take a significant amount of time to complete; your "Line send delay:" value must be greater than or equal to the longest time required for either command to complete on your slowest child device.

--Cameron