How to Set Up an SSH Jump Server

Teleport 4.4 Announcement, ssh and Teleport

Introduction

In this blog post we’ll cover how to set up an SSH jump server. We’ll cover two open source projects.

  1. A traditional SSH jump server using OpenSSH. The advantage of this method is that your servers already have OpenSSH pre-installed.
  2. A modern approach using Teleport, a newer open source alternative to OpenSSH.

Both of these servers are easy to install and configure, are free and open-source, and are single-binary Linux daemons.

What is an SSH Jump Server?

An SSH jump server is a regular Linux server, accessible from the Internet, which is used as a gateway to access other Linux machines on a private network using the SSH protocol. Sometimes an SSH jump server is also called a “jump host” or a “bastion host”. The purpose of an SSH jump server is to be the only gateway for access to your infrastructure reducing the size of any potential attack surface. Having a dedicated SSH access point also makes it easier to have an aggregated audit log of all SSH connections.

Why not call it an SSH proxy? Partly due to historical reasons. In the earlier days of SSH, users had to SSH into a jump host and from there, they had to type ‘ssh’ again to “jump” to a destination host. Today, this is done automatically and Teleport does, in fact, use the term “SSH proxy” to describe this functionality.

Setting up an SSH Jump Server

A good security practice is to have a dedicated SSH jump server, i.e. not host any other publicly accessible software on it. Also, not allow users to log into a jump server directly. There are several reasons for why:

It is also a good idea to change the default TCP port on the SSH jump server from 22 to something else.

Let’s go over configuring an SSH jump server using two open-source projects. We’ll start with OpenSSH as it’s the most common.

But first, let’s make a few naming assumptions for the examples used below:

We’ll also assume that proxy.example.com is the only machine accessible from the Internet.

OpenSSH

This SSH server comes bundled by default with most Linux distributions and there’s nearly 100% chance you already have it installed. If the server is accessible via proxy.example.com then you can access other servers behind the same NAT boundary via -J command line flag, i.e. on the client:

$ ssh -J proxy.example.com 10.2.2.1

In the example above, the jump server is used to access another host on an AWS VPC with an address of 10.2.2.1. So far, this looks pretty easy.

To avoid typing -J proxy.example.com all the time, you can update your client’s SSH configuration in ~/.ssh/config with the following:

Host 10.2.2.*
    ProxyJump proxy.example.com

Now, when a user types ssh 10.2.2.1 their SSH client will not even try to resolve 10.2.2.1 locally, but instead will establish a connection to proxy.example.com which will forward it to 10.2.2.1 within its VPC.

Next, we need to harden the server configuration a bit by disabling interactive SSH sessions on the jump server for regular users, but leaving it turned on for the administrators. To do this, update the sshd configuration, usually in /etc/ssh/sshd_config with the following:

# Do not let SSH clients do anything except be forwarded to the destination:
PermitTTY no
X11Forwarding no
PermitTunnel no
GatewayPorts no
ForceCommand /sbin/nologin

The example above will work for Debian and its derivatives, we advise to verify the existence of /sbin/nologin.

This will work for as long as the jump server has accounts for all SSH users, which is inconvenient. Instead, consider creating a separate user account on the jump server dedicated to “jumping users”. Let’s call it jumpuser and update the configuration:

Match User jumpuser
  PermitTTY no
  X11Forwarding no
  PermitTunnel no
  GatewayPorts no
  ForceCommand /usr/sbin/nologin

And the users will have to update their client SSH configuration with:

Host 10.2.2.*
    ProxyJump [email protected]

For more information on how to fine-tune SSH jump configuration to your particular situation, consult man ssh_config and man sshd_config.

Needless to say, the setup above works only when the public SSH keys are properly distributed not only between clients and the jump server, but also between the clients and the destination servers.

Teleport

Teleport is a much newer SSH server, which was released in 2016. Unlike OpenSSH, Teleport is a highly opinionated SSH implementation:

Teleport 4.4 Announcement, ssh and Teleport

In addition to having a modern proxy functionality, Teleport offers a few advantages over traditional SSH:

Teleport always comes with a proxy (i.e. the same thing as a “jump server”) and there are no special instructions for setting it up. We suggest you start by downloading Teleport for your platform and follow the quick start guide.

Conclusion

In this blog post we covered how to set up an SSH jump server using two open-source projects: OpenSSH and Teleport. Which one should you choose?

Use OpenSSH if:

Use Teleport if:

Related Posts

ssh
 

Try Teleport today

In the cloud, self-hosted, or open source

View developer docs

This site uses cookies to improve service. By using this site, you agree to our use of cookies. More info.