Best Practices for Jumpbox Routes

See SSH Jumpbox Routes for an introduction.

Overview

This topic discusses configuring an SSH jumpbox route using OpenSSH.

We strongly recommend a dedicated SSH jumpbox without any other publicly accessible software on the machine. Occasionally, multiple jumpboxes (a jumpbox route) may be required to access a target machine that is behind several layers of network security.

Assumptions

We want:

The jumpbox to forward SSH connections to our internal hosts. Users must authenticate to the SSH jumpbox and the internal target host. Users need valid credentials for both hosts.
A single shared user for everyone with no interactive terminal sessions allowed.
Users to connect to internal target hosts using Secret Server’s jumpbox route feature, which uses the jumpboxes as jump route “levels” to ultimately launch a target secret that has this jumpbox route selected.

Best Practices

We recommend not allowing users to log into a jumpbox directly because they might introduce security issues by:

Inadvertently updating the jumpbox configuration
Using the jumpbox machine for unrelated tasks.
Making copies of cryptographic keys used to access destination servers.

We recommend changing the default TCP port on the SSH jumpbox from 22 to something else.

Example Setup

The following example uses these conventions:

The organization domain is example.com.
The DNS name of the jumpbox is proxy.example.com, which is the only machine accessible from the Internet.

Task 1: Launching a New Linux Instance

Stand up a Linux instance on your cloud provider. We use Ubuntu 20.04 LTS because it is simple, well-supported, and includes the recently released OpenSSH 8.2.
Set up a firewall or security group policy to restrict connections to the jumpbox to port 22 (SSH).
Allow connections only from IPs you trust.

Task 2: Configuring OpenSSH

Read and apply Mozilla’s OpenSSH Security Guidelines.

The guidelines only cover up to OpenSSH 6.7. Most are still relevant to OpenSSH 8.2.
OpenSSH is bundled by default with most Linux distributions. It is almost certain your Linux machine already has it installed. If the server is accessible via proxy.example.com, clients can access other servers behind the same NAT boundary via the -J command line flag. For instance: $ ssh -J proxy.example.com 10.2.2.1

In the example above, the jumpbox is used to access another host on an AWS VPC with an address of 10.2.2.1.

Task 3: Configuring Public Key Authentication and Disabling Root Logins

Configuring the sshd_config File

In your new jumpbox’s /etc/ssh/sshd_config file, consider adding the following SSHD config parameters:

Copy

# Supported HostKey algorithms by order of preference.
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_rsa_key
 
# Password based logins are disabled - only public key based logins are allowed.
AuthenticationMethods publickey
 
# LogLevel VERBOSE logs user's key fingerprint on login. Needed to have a clear audit track of which key was using to log in.
LogLevel VERBOSE
 
PermitRootLogin no
 
# Log sftp level file access (read/write/etc.) that would not be easily logged otherwise.
Subsystem sftp  /usr/lib/ssh/sftp-server -f AUTHPRIV -l INFO

The setup above works only when the public SSH keys are properly distributed, not only between clients and the jumpbox but also between the clients and the destination servers. With these settings, password authentication is disabled.

Setting Key Exchange Algorithms, Ciphers, and MACs

Consider which algorithms and key types you want to support. Mozilla recommends the following key types (more restrictive than the OpenSSH defaults):

In /etc/ssh/sshd_config, add:

Copy

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

Task 4: Disabling Forwarding

Next, harden the server configuration by disabling interactive SSH sessions on the jumpbox for regular users, leaving it turned on for the administrators. To do this, update the sshd configuration /etc/ssh/sshd_config with the following:

Copy

# Do not let SSH clients do anything except be forwarded to the destination:
AllowAgentForwarding no
AllowStreamLocalForwarding no
X11Forwarding no

If you only have a few users, consider creating a separate user account on the jumpbox dedicated to “jumping users.” For example, call it "jumpuser" and update the configuration /etc/ssh/sshd_config:

Copy

Match User jumpuser
  PermitTTY no
  X11Forwarding no
  PermitTunnel no
  GatewayPorts no

Task 5: Changing the Default SSH Port

If you do not want to restrict access by IP address in your security group rules, consider changing your default SSH port. This will deter many basic bots.

In /etc/ssh/sshd_config, add Port 37271.

Task 6: Testing Configuration and Restarting SSHD Service

You can test your configuration with sshd -t, then restart the SSHD server. Make sure you can still ssh into the machine before you continue!

Task 7: Send Your Users’ SSH Keys to the Jumpbox

Add the jump user’s public keys to the /home/jumpuser/.ssh/authorized_keys file. These keys can be stored in Secret Server and used during the Jumpbox Route launch session.

Using Bastion Hosts with Secret Server and Jumpbox Routes

Please see Creating and Testing Secrets for Jumpbox Routes.

References

Johnson, Brian. “How to Create a Bastion Host | Part 1 of a Step-by-step Tutorial.” Strongdm, 25 March, 2021, https://www.strongdm.com/blog/bastion-hosts-with-audit-logging-part-one, Accessed 12 October, 2021

Kontsevoy, Ev. "How to Set Up an SSH Jump Server." Teleport, 30 March, 2021, https://goteleport.com/blog/ssh-jump-server/, Accessed 12 October, 2021

Tashian, Carl. “DIY SSH Bastion Host.” Smallstep, 08 July 2020, https://smallstep.com/blog/diy-ssh-bastion-host/, Accessed 12 October, 2021