How-To: Use Logon Actions to connect to a secondary host behind a Jumphost/Gateway

[jdev]

Need to connect through an SSH gateway/jumphost server to reach another host behind that server?

First, watch this video about SecureCRT's Dependent Sessions feature.

If it turns out that the SSH2 server on your jumphost does not support port forwarding, then you can resort to using the techniques described here as follows to help you get connected to secondary host.

Here is the general initial setup pattern:

1. Test SecureCRT's Dependent Sessions functionality -- if it works, skip the approach described below, and use dependent sessions since that is the simplest/best interaction possible.
   
   
2. Create a folder in the Session Manager that will house all of the sessions that will use the same jumphost.

   

3. Create a saved session to your jumphost (if you already have a session to your jumphost, just create a copy of it), and place it in the new folder you created.

   
   

   Although it's not a security best practice, many individuals -- for the sake of convenience -- insist on being able to store username and password as part of the session configuration.
   If you're inclined to save credentials for the jumphost, do so by saving them in the Session Options's SSH2 category for your jumphost session as shown here:
   
   The username and password stored as shown above are used to authenticate to the jumphost.
   Later on, I'll address where to store creds (if you're inclined) for authenticating to the secondary host.
   

4. Connect to your new jumphost session.
   Once you are at the point where you'd normally type in your ssh user@host command, take a look at the last few characters of the shell prompt on that line. In my case, the shell prompt of my jumphost looks like this:

   [user@remote-host:~] <== Note that there's a trailing space here

   
   
   

   Make a note of the last few characters of your shell prompt. In this case, I'd use the last two right-most characters of the shell prompt "] "
   Note that I'm including the trailing space character, since my blinking cursor is one space/column away from the closing ] in the jumphost shell prompt. If when you connect to your jumphost, the shell prompt shows the cursor blinking immediately next to the last character of the shell prompt, then you should not include a trailing space).
   This information is needed later on when driving the automated process of connecting to the secondary host.
   
   
5. Edit the properties of the current session (Options > Session Options).
   
   1. In the Connection > Logon Actions category,
      1. Enable the "Automate logon" option
      2. Disable the "Send initial carriage return" option
      3. Delete the first two entries in the Expect...Send listing. They're there to show you an example.

         

      4. Press the [Add...] button to create a new Expect...Send entry.
         1. In the Expect field, enter the last few characters of the shell prompt. You're telling SecureCRT what to look for to know it's ready to send commands.
         2. In the Send field, enter the ssh user@host command, using the exact username and hostname/IP you need to reach the secondary host.

            

         3. Press the OK button.
         
         
      5. Press the [Add...] button again to create yet another new Expect...Send entry.
         1. In the Expect field, enter the last few characters of the password prompt. Use something like "word:" here, because it may be that some hosts use "Password:" with a capital letter, and others may present "password:" with lower-case p.
         2. Enable the Hide option below the Send field so that others in your vicinity will not be able to see the super secret password you're entering here.
         3. In the Send field, enter the password required to authenticate to the secondary host you entered in the earlier Expect...Send entry

            

         4. Press the OK button.
         
         
      6. Review the Logon Actions work you've done so far. You should see one row/entry that is waiting for (Expect) the last few characters of your jumphost's shell prompt, and sending the ssh user@host command that will get you to the secondary host, and another row/entry that is waiting for (Expect) the last few chars of the password prompt, and Sending the password.

         

   2. Select the Terminal > Emulation > Advanced category and make sure the Ignore window title change requests option is enabled. This step is taken because we want the tab name to always reflect the name of the secondary host to which you'll be connected.

      

   3. Select the Appearance > Window category and enable & set the Title bar to match the hostname or IP address of this specific secondary host. This is done to set the initial tab/window title to reflect the secondary host's name/IP.

      

   4. Press the OK button to save your changes to the current session.
   
   
6. Close the tab you have open that is currently connected with the session we just edited.
   
   
7. In the Session Manager, rename the session you just edited to match the Secondary Host's name/IP.
   
   
8. Connect to the host to see if it works. If you don't see SecureCRT attempting to run the ssh user@secondary_host command, then it most likely means you didn't set up the first Expect entry in the Logon Actions correctly. Review what the shell prompt on your jumphost looks like and edit the first Expect entry in the session's Logon Actions category to match the last portion of the jumphost's shell prompt. Keep editing and testing until you have the session configured to get you all the way connected to your secondary host by simply double-clicking on the session's entry in SecureCRT's Session Manager.

Creating Subsequent Sessions: Copy the existing session
Once your initial setup is complete, and you have a session that gets you connected to the jumphost and automatically runs the remote ssh command to get you to the remote host, you get to leverage the work you've just accomplished.

To create sessions for other hosts behind this same jumphost/gateway:

1. Make a copy of the existing session you created in the initial setup described above.
   1. Right-click the session and choose Copy
   2. Right-click the session again and choose Paste
   3. Or, select the session in the Session Manager and then press the Ctrl+C and Ctrl+V shortcut keys in sequence to do the copy and paste.
2. Rename the copy you just made to reflect the name of the additional secondary host you want to reach.
   
3. Edit this new copy's session properties to reflect the additional secondary host you're targeting:
   1. In the Logon Actions category, change the first Expect...Send entry such that the ssh user@host command reflects the additional secondary host's name/IP.
   2. Select the Appearance > Window category and set the Title to match the hostname or IP address of the additional secondary host's name/IP.

How does this approach benefit you in the long run?
SecureCRT allows you to edit the properties of multiple sessions at once. See https://www.vandyke.com/support/tips/multisessions.html

When editing multiple sessions in bulk, the properties of the first session are shown in the Session Options window.

When editing the Logon Actions portion of multiple sessions at once using this mechanism, the following is possible:

IFF (IF and only iF):

1. All of the sessions have the exact same number of Expect/Send rows, and
2. You modify exactly one (and only one) value from either the Expect or the Send field and
3. You are running SecureCRT 7.3 or newer (earlier versions of SecureCRT did not support this surgical logon actions modification capability)

Then that same value, if present in the other sessions, will also be changed without affecting the values of the other Logon Action rows.

WARNING: In every other scenario (e.g. if you're running a version of SecureCRT pre 7.3, or if you change more than one token element of the Logon Actions field), the result will be that all of the sessions being edited will have their Logon Actions' rows (Expect/Send fields and all) set to match every component of the first session's Logon Actions (the one that is visible as you're editing Session Options - Multiple)

This means that if you have a password saved in a Send field, and that password is present in the Send fields of other sessions currently being edited, changing only that password field will result in that password being updated in all of the sessions, without any of the other Expect or Send field values being modified/lost.

This graphic represents the concept of n sessions being edited in bulk, and the 'ssh user@...' portion of the Logon Actions (the Send field in row 1 of each session) has a unique host name different for each session.

• The first session has: ssh user@secondary_host1.
• The 2nd session has: ssh user@secondary_host2.
• The pattern continues with a different hostname in the Send field of the 1st row of each session being edited all the way until the nth session which has: ssh user@secondary_hostn as the target.

The idea is to modify only one Expect or Send field in one row and nothing else. If this singular edit approach is what you do when editing sessions in bulk, then all of the sessions will be modified such that whatever Send or Expect value you changed will have that same old value updated to the new value, and the remaining Logon Action rows and their Send/Expect fields will remain as-is.

With the bulk-editing capability I've described above, if the password for these hosts ever changes, you would:

1. Right-click on the folder containing all of these sessions and choose Properties
2. Select the Connection > Logon Actions category.
3. Locate the Expect...Send entry that is responsible for sending the password. Select this entry and press the Edit button.
4. Enter the new password in the Send field.
5. Leave everything else as it is; making any other changes could result in making all of the other sessions' Logon Actions look exactly like this session's -- that would mean all sessions are ssh'ing to the same remote host).
6. Press the OK button.

Note: As a point of caution, in the event that you're unsure of how this works, and in case you inadvertently modify two fields instead of one, it is advised that you consider adopting the habit of performing a Tools > Export Settings... backup operation prior to attempting such a change so that you can restore your Logon Actions if the bulk edit operation gets botched in error.