Using SSH Through A Bastion Host Transparently

By Rob Giseburt

A Bastion host is a special purpose computer on a network specifically designed and configured to withstand attacks. The computer generally hosts a single application, for example a proxy server, and all other services are removed or limited to reduce the threat to the computer. It is hardened in this manner primarily due to its location and purpose, which is either on the outside of the firewall or in the DMZ and usually involves access from untrusted networks or computers.

Having a bastion host is a good security practice commonly deployed to strengthen yet simplify security controls of an environment.  However, adding bastion hosts creates complexity in remote execution of scripts or deployment tasks.  Here we will be using a bastion host to serve as a SSH server that we can “hop” through into another machine (real or VM), allowing users to automate remote task execution over SSH. We will be demonstrating how to make that connection transparent and automatic, not only for manual SSH connections but also for programmatic SSH connections such as with GIT or Ansible.

The purpose of using a bastion host for access is clearly a matter of increased security. We won’t be going deeply into the security implications in this article. Instead, we will discuss

  1. The mechanics of using SSH to connect to the bastion host, and from there SSH to another machine without having to store authentication information on the bastion host.
  2. Making the connection through the bastion host to the destination machine in one step.
  3. Making the connection transparently using the bastion host based on destination.

In follow-up posts, I’ll cover these related topics:

  • Dynamically located SSH bastion hosts with AWS
  • SSH connection multiplexing, port forwarding, and use as a SOCKS proxy
  • Using SSH bastion hosts with AWS, and dynamically locating them with EC2 tags
  • Configuring Ansible to use an SSH bastion host

1. SSH to the bastion, and beyond

In order to efficiently and (arguably) securely connect to multiple machines from one machine, we’ll be using Public Key Authentication in SSH. There are many references on the internet about how to generate key pairs that can be used for ssh, such as for GitHub, Amazon AWS, Google Compute Engine, and there’s always the ssh-keygen(1) man page.

However you get there, we’ll need to end up with:

  • One or more key pairs in ~/.ssh/ that are secured by password(s).
    • From here on we’ll assume one key pair per machine you’re connection to, including one for the bastion host itself. You could of course use a single key pair for all machines, or one key pair for the bastion host and another for all the other machines, or any combination of the above.
  • That each machine (including the bastion host) already has the relevant public-key copied to ~/.ssh/authorized_keys, thereby granting access to the holder of the corresponding private key — hopefully, that’s just you! This should be tested and proven to allow login to that machine from the client machine without an account password. If it fails, check for incorrect permissions to the file and it’s containing directories, and verify that authorized-keys is not disabled in the sshd config of the destination machine.
  • ssh-agent(1) is running and all of the key pairs to be used have been ssh-add(1)ed, thus allowing each key to be used without (further) entering a password.
    • NOTE: In OS X, the ssh-agent is automatically started at login, and has been extended to grab an SSH key’s passphrase from the user’s keychain. When you generate a key, call ssh-add with the OS X-only -K option to add it’s passphrase to the user’s keychain. The automatically started ssh-agent will then be able to access those keys in the keychain as long as the keychain is unlocked. (The keychain is usually unlocked as long as the user is logged in and the screen isn’t locked.)
    • For linux/unix OSs, it’s recommended to add ssh-agent to the shell’s login, and then call ssh-add after login and before using ssh.

With that the basics of public-key authentication are handled: You can ssh into the bastion host without a password. If you have means to directly access to the various machines you intend to connect to through the bastion host (such as through a VPN tunnel or temporarily connecting to the same physical network) then you should be able to ssh into them without an account password as well.

However, you will likely not be able to ssh through the bastion host into the destination machine with simple ssh commands, since the bastion host doesn’t have the private keys to the destination machine. We don’t want to place our private keys onto the bastion host for many reasons. First, we don’t want to specifically give the keys to the inside machines right on the outwardly-accessible bastion host. Second, there may be many people accessing through that bastion host via that same account, and we don’t want the keys of those various users on the bastion.

In order to solve this problem without putting the private keys onto the bastion host, we’ll need to enable “SSH agent forwarding,” which allows the ssh agent running on your local machine to provide the keys to the connection from the bastion host to the destination machine. There’s a great article on setting up ssh agent forwarding on GitHub.

Note: There are many that believe that the ForwardAgent capability is a misfeature and opens you to security risks if the bastion is compromised. When practical it’s advised to avoid this method and use the other methods listed below.

In short, you can enable forwarding one of two ways:

  • Per-connection — add -A to the ssh line when connecting to the bastion host:
  • ssh -A
  • Per-host via ~/.ssh/config — add a section for the bastion host with ForwardAgent yes:
        ForwardAgent yes
    • Don’t use a wildcard host — you will be extending access to all of the unlocked keys in your ssh-agent to every machine you ssh to, including through other subsystems that may use ssh, such as Ansible and git. This is a bad idea.

We’ll go with the configuration-file method, since we’re going to build upon that shortly.

With ssh-agent running locally and usable, the keys ssh-add‘ed to it so that they are unlocked, each machine having the correct public key in it’s ~/.ssh/authorized_keys, and ssh agent forwarding enabled for the bastion host, you should be able to ssh through the bastion host and then ssh from there into the destination machines:

my_machine# ssh ssh echo 'Success!'

2. SSH through the bastion in one command

We can combine the two connection steps into one line, simplifying the process:

my_machine# ssh ssh echo 'Success!'

This simply executes the second ssh call on the bastion host instead of opening a shell. This is almost as if we had done the connection in two steps, except that when we disconnect from the destination machine it’ll also close the connection to the bastion host.

3. SSH through the bastion, transparently

The next step is to eliminate the need to connect to the bastion host explicitly, but instead when we attempt to ssh to the destination machine, we will automatically and transparently connect to the bastion host and then hop to the destination machine in one call.

We’re going to utilize the ssh ProxyCommand setting applied to the specific host or hosts to tell ssh to setup our connection to the bastion host first, then use that connection to ssh to the final machine. On disconnect this will automatically tear down the intermediate connection as well.

    ProxyCommand ssh -W %h:%p

This tells ssh to run the command ssh -W host:port and then talk to the standard in/out of that command as if it’s the remote connection.

That proxy ssh command has several things going on. The real magic is the -W host:port, which tells it to redirect the standard in/out to the specified host and port, which was designed specifically for using ssh as a ProxyCommand. And finally, we have the %h and %p tokens that will get replaced in the ProxyCommand call, which allows us to use wildcards and multiple host names in the Host ... line.

With this setup, connecting to through the bastion host is automatic and transparent:

my_machine# ssh echo 'Success!'

 What’s next?

In the next post, we cover using bastion hosts in AWS and dynamically locating the SSH bastion hosts based on EC2 tags.

Updated 8/31/2016 to reflect that the -A option of ssh is now considered a security risk, and it was removed from examples where it was unnecessary.


5 thoughts on “Using SSH Through A Bastion Host Transparently

    1. Rob Giseburt Post author

      Hi Jay,

      I assume you mean what about if there are multiple bastion hosts. There are a few way to interpret this.

      One interpretation is “What if we need different bastion hosts for different machines?” We cover this in method 3 of this post by setting the bastion for a specific destination-host pattern, and further in the next post for fynamically locating the bastion:

      A second interpretation is “What if we have to chain bastion hosts?” I haven’t tested this, but you would essentially just configure the bastion to use bastion hosts for the eventual destinations. It should be possible to chain them arbitrarily deep, but you’ll likely run into reliability/performance issues pretty quickly.



  1. Pingback: issue #5: PHP 7, Swift, Let’s Encrypt, Zipnish, Sysadvent and many more | Cron Weekly: a weekly newsletter with the latest linux news & tools

  2. snowphil

    You don’t need the `-A` in ProxyCommand (the local ssh client opens first one connection to the bastion host as specified in ProxyCommand, and then makes the next connection through the stdin/stdout of that sshd process on the bastion, which are pointing at the actual machine you want to access).

    Forwarding your agent to the bastion is unnecessary and makes it easier for somebody who has root on the bastion host to authenticate as you.


    1. Rob Giseburt Post author

      @snowphil, I believe you are correct that -A is unnecessary. I’ll update the article accordingly.

      Thank you,



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s