Jump Server config

[ever360]

I'm new to secureCRT and I'm not really sure if this post is in the correct place.
Our company wants us to start using a jump server before we log into our final destination. We will log into the jump server with our admin credentials and then log into our destination as root via stored SSH keys on the jump server.
Is there any way of getting secureCRT to log into the jump server then hop to the destination using the session manager?
Me and my team honestly just want to double click on a stored session, fill out our password, and then get to the destination as root.

[bgagnon]

Hi ever360,

What version of SecureCRT are you using?

As long as v7.1 or later, this feature should make the task quite easy:

Changes in SecureCRT 7.1 (Beta 1) -- February 26, 2013
------------------------------------------------------

New features:

• Added support for dependent sessions so that a connection can be made to a jump host or SSH gateway before the session is connected.

Essentially, you would:

• Create a session to the jump host
• Create a session to the final host
• In the final host session, in the Connection/SSH2 category, from Firewall dropdown, choose Select Session..., then select the jump host session
  
• Connect final host session

But, I may need you to elaborate on this statement:

We will log into the jump server with our admin credentials and then log into our destination as root via stored SSH keys on the jump server.

The private key files you need to use for authentication from jump host to end host are actually stored on the jump host?

[ever360]

yes the ssh keys are on the jump host

[bgagnon]

Hi ever360,

And I assume this is a Linux jump host?

If so, then you are going to have to use the ssh client on the jump host for the connection from jump host to final host as publickey auth in SecureCRT requires being able to point to the key file within the session (ie: it's stored locally/accessible to machine on which SecureCRT is running). Or using SSH agent forwarding if both connections were under the same user context (or at least used the same public/private keypair).

You can simplify/automate the connection from jump host to final host a bit by enabling Automate logon (in the jump host session you use in SecureCRT for the initial connection) in the Connection / Logon Actions category of Session Options and then configuring the Expect/Send sequences accordingly.

Assuming you've automated authentication *to* the jump host within the jump host session (ie: saving username and password, if desired, when prompted if that's the auth method used to jump host), you could have:

Expect:                        Send:
jumpHost_prompt_after_auth     ssh -i "path_to_key_file" [any other options needed] root@final_host

[mdella]

Hey Ever360...

So just to be clear on a few terms and purposes...

What we have here are a couple of jump hosts (by couple, meaning they get into our environment two different ways in the event of network failure, etc). Our jump hosts are actually CentOS 7 VMs running under KVM of another machine and are located in our DMZ networks.

So from a networking perspective, a user on the internet can ssh to a jumphost VM located on one of our DMZs (behind a cisco ASA in this case) on port 22. To insure that we have full control over individuals as well as auditing capabilities, EACH user has their own account on the jump hosts (no one has root directly, just admins have sudo, root passwords set at random values that NO ONE has, and root logins disabled on ssh) (more on this configuration later). This insures that each user comes into their own named account. They can put whatever keys they want in the authorized_keys file, etc. And if we have to terminate a user, rather than chase down every key out there, we just disable the accounts on the jump hosts first.

We have a series of scripts that "search and destroy" any private key on the jump hosts (not 100% accurate, but gets people from randomly generating keys there). The jump hosts then have port 22 access to all required "internal" machines again via the ASA.

With this in place, we insure that the following options are set on the /etc/ssh/sshd_config file on the jumphost:

KeyRegenerationInterval 30m
ServerKeyBits 2048
LogLevel VERBOSE
LoginGraceTime 30s
PermitRootLogin without-password
RSAAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
PasswordAuthentication no
GSSAPIAuthentication no
AllowAgentForwarding yes
X11Forwarding yes
ClientAliveInterval 30
ClientAliveCountMax 5
MaxStartups 10:35:40
PermitTunnel no
Ciphers aes256-ctr,aes192-ctr
MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-ripemd160

There are reasons for each of these configuration deviations, but you can google most or ask for more detail if it matters.

on the jumphost, we also modify the /etc/ssh/ssh_config file to insure that we connect with certain parameters:

Host *
VisualHostKey yes
GSSAPIAuthentication no
AddKeysToAgent yes
PreferredAuthentications publickey,password

---

What this does is creates a "middle" jump host that is rather difficult to get into if you *DONT* have a valid key (we happen to use Elliptical Keys rather than RSA/DSS keys here mostly although there are some issues with that and SecureCRT atm). It also sets up the outbound path to be "compliant" with certain security parameters we wanted (since those are "out" from the jump box, the end user could override them, but as a default they set up our standards).

On all our "internal" hosts that people actually want to get onto, we have a few different methods of dealing with that.

1. The most user friendly (and of course least secure and an audit nightmare) is to copy everyone's public keys into the /root/.ssh/authorized_keys file... Typically we only see developers do this on machines that they know we are going to destroy periodically in development environments (you never see this in production)

2. A variation on that theme is where we create a common "user" account on say or CQ (or QA) machines that has everyones public keys in the ~/.ssh/authorized_keys file. The end user then has to use sudo (and know the qa account password) if they want root privledges. At least from an audit viewpoint we have the sudo logs to sort of see what happened when things go wrong (and they do all the time).

3. Our production machines are set up similar to the jump box. That is, each user has an account (that is distributed across the environment via chef or puppet) with their own personal ~/.ssh/authorized_keys file. The /etc/sudoers file is also distributed out via puppet so that we can authorize some users with one set of elevated privileges and not others.

Even though we can use puppet/chef to remove accounts when users leave or their accounts are compromised, we typically don't do that for up to a week or more after events. Rather, we remove the account information on the jump box and leave everything else (some people have scripts running on their accounts, automation, etc... we don't always know).

So... how does a user get to a box inside the network without having to jump all over the place? Well, Brenda sort of posted that above.

1. Create a session entry as IF you had direct access to the final destination (including keys, account name, etc)
2. Create a session entry specifically for your jump box(s).
3. In your session entry for the final destination, enter in the "Connection -> SSH2 -> Firewall:" a "Select Session" and select your connection to the jump box.

Make SURE you have either globally or in the "Connection -> SSH2 -> Advanced -> Enable OpenSSH agent forwarding" turned on so that your box can answer the chain of authentication queries. Easiest if you set this in your "Global Options: SSH2 -> Add keys to agent" and "Enable OpenSSH agent forwarding"

If this is all done correctly, then when you click on your session entry for your final box, you should connect automatically all the way through without having to type anything other than (once) the password to decrypt your private key (I sure hope you did encrypt it when you created it)

---

Hope that helps

Marcos