SSH Jump Server Principles and Configuration: Seamless Jump Connection, Direct Access to Target Host in One Step

Preface

In daily operations or development work, we often need to access servers deployed in the internal network. However, due to security policies or network topology restrictions, internal servers do not directly expose ports to the external world, preventing us from "directly connecting" to them. In such cases, a jump host (Jump Host/Bastion Host) becomes an essential relay point:

• First, log in to the jump host via SSH;
• Then, log in to the target server from the jump host.

While this process ensures security isolation, it also brings a certain degree of inconvenience: we have to "log in twice" every time, and sometimes even manually enter passwords multiple times or switch between multiple terminal windows, which is quite cumbersome. Sometimes, it's also necessary to frequently copy and paste commands between the jump host and the target host, which inevitably affects efficiency.

Is there a way to simplify the connection process while maintaining security, allowing us to "reach" the target host directly in one step? The answer is yes. This article will explain how to use SSH configuration—mainly ProxyJump (the -J parameter) or ProxyCommand—to automate the "jump host" step, enabling us to connect directly to the internal server from our local machine with a single command.

Background Information

• Bastion Host / Jump Host A bastion host is typically located at the edge of a controlled network and serves as the sole secure transit point with open SSH/port access. External users can only access other internal network hosts by logging into the bastion host first, acting as a security barrier.
• Pain Points of Double Login
  1. Cumbersome operations: Every time, you need to ssh jump-host to log in, then ssh target-server.
  2. Repeated credential entry: If key sharing or SSH Agent forwarding is not set up, you often have to re-enter the password multiple times.
  3. Error-prone: Frequent switching between multiple servers may lead to accidentally executing commands in the wrong terminal window.
• The Role of SSH Configuration Forwarding
  • Using SSH's built-in proxy functionality, the local SSH client can automatically establish a tunnel through the bastion host when connecting to the target host, eliminating the need for manual double login.
  • For users, it feels like directly logging into the target server; for the network, data is still forwarded via the bastion host, satisfying policy requirements from both security and compliance perspectives.
• Compatibility and Version Requirements
  • ProxyJump (-J) requires OpenSSH 7.3+.
  • ProxyCommand is compatible with earlier versions of SSH and has broader compatibility, though configuration is slightly more complex.

By using these methods, we can log into the target server "in one step" while maintaining the integrity of network and security policies. Next, we will provide specific examples to illustrate how to configure and use these methods.

Traditional SSH Two-Step Login Method

In the traditional SSH login process, especially in scenarios involving jump servers, we typically need to perform the following two steps:

1. Step 1: Log in to the jump server Assume we already know the jump server address jump-server.dealiaxy.com and the open port (e.g., 10023). First, we connect to this jump server via SSH:

   ssh -p 10023 user@jump-server.dealiaxy.com
   

   At this point, the SSH client will ask us to provide login credentials (such as a password or key). If we haven't configured our public key on the jump server, we'll need to manually enter the password or configure an SSH key to enable passwordless login.

2. Step 2: Log in from the jump server to the target host After logging into the jump server, we still need to perform a second SSH login to access the target server target.dealiaxy.com:

   ssh user@target.dealiaxy.com
   

   At this point, we again need to provide the login credentials for the target host or configure SSH keys for passwordless login. If the target host and the jump server are not on the same network segment, we might also encounter issues with network policies or firewalls, leading to connection failures.

Drawbacks and Pain Points

1. Cumbersome operational steps: Every time, multiple commands need to be entered, making the operation complex and time-consuming.
   • If the target server is in a different network environment, the number of steps for this operation may increase, further reducing efficiency.
2. Multiple credential entries: Each time, passwords or SSH keys need to be entered manually, which is error-prone, especially when key management is not done properly.
3. Switching windows or multitasking: Multiple SSH sessions need to be opened separately to manage the jump server and the target server, which can lead to a cluttered interface and is difficult to manage, particularly during complex operations.

Principle Introduction: SSH Jump Host Configuration

In a traditional SSH login process, we need to manually perform two SSH login operations. This not only increases the workload but can also lead to connection delays and unnecessary repetitive steps. So, how can we simplify this process while ensuring security?

The answer is to use SSH Jump Host configuration to achieve an automated connection process. SSH itself provides two main ways to handle this jump host scenario: ProxyJump and ProxyCommand. Both methods allow us to complete the connection from the local machine to the target server in a single command, without the need to manually log in to the jump host.

1. ProxyJump (Recommended Method)

Starting from OpenSSH version 7.3, SSH introduced a new parameter -J, which allows us to directly specify the jump host. By using the -J parameter, we can have the SSH client automatically connect to the jump host first, and then forward traffic to the target host through the jump host to complete access to the target host. This method is concise and direct, and is recommended for use.

Example Command:

ssh -J user@jump-server.dealiaxy.com:10023 user@target.dealiaxy.com

In this command, the address (user@jump-server.dealiaxy.com) and port (10023) of the jump host are specified after -J. SSH will first establish a connection with the jump host, and then forward traffic to the target server target.dealiaxy.com through the jump host. The entire process only requires a single login operation, greatly simplifying the access procedure.

2. ProxyCommand (Better Compatibility)

For older versions of SSH clients, or in some special scenarios (e.g., when using other protocols or more complex forwarding configurations), ProxyCommand can be used to implement the jump host configuration. ProxyCommand is a mechanism in SSH clients that allows us to define a custom command to establish a connection. Through it, we can specify the command for the jump host.

Example Command:

ssh -o "ProxyCommand ssh -W %h:%p user@jump-server.dealiaxy.com -p 10023" user@target.dealiaxy.com

In this command, the -o "ProxyCommand" option specifies a custom command to connect through the jump host. Specifically, ssh -W %h:%p forwards the target host (%h) and port (%p) to the jump host, and then establishes a connection to the target host through the jump host.

Although this method is more complex to configure, it offers greater flexibility and supports more customized requirements.

By configuring a jump host, we can avoid manually logging into the jump host and then to the target host each time. Whether using ProxyJump or ProxyCommand, both can significantly simplify our operational process and improve efficiency. ProxyJump is the recommended method because it is more concise, easier to use, and compatible with most modern OpenSSH client versions.

In the next section, we will provide a detailed guide on how to configure these options to quickly achieve seamless SSH jump host connections.

Jump Server Configuration Method:

Method 1: Using the -J (ProxyJump) Parameter

As previously mentioned, the -J parameter is a feature provided by OpenSSH 7.3 and later versions, which allows us to specify a jump host in a single command, thereby simplifying the process of accessing servers within a private network. Compared to the traditional method of logging in twice, using the -J parameter lets us log in to the target host directly through the jump host, avoiding the cumbersome process of two separate SSH logins.

1. Basic Syntax

The basic syntax for the -J parameter is as follows:

ssh -J <jump-user>@<jump-host>:<port> <target-user>@<target-host>

• <jump-user>: The username for the jump host
• <jump-host>: The address of the jump host (can be a domain name or IP)
• <port>: The port for the jump host (defaults to 22, can be modified as needed)
• <target-user>: The username for the target server
• <target-host>: The address of the target server (can be a domain name or IP)

2. Example Command

Suppose you have the following connection information:

• Jump Host: jump-server.dealiaxy.com, Port: 10023
• Target Server: target.dealiaxy.com
• Username: user

You can use the following command to connect directly to the target server through the jump host:

ssh -J user@jump-server.dealiaxy.com:10023 user@target.dealiaxy.com

When you execute this command, the SSH client first establishes a connection with the jump host jump-server.dealiaxy.com through the specified port (10023), and then automatically forwards the connection from the jump host to the target server target.dealiaxy.com, just as if you were logging in to the target server directly. This process is completely transparent to the user; you only need to provide credentials once (username and password or SSH key) to complete the connection.

3. Passwordless Authentication

If you have already configured an SSH key pair and added the public key to the authorized keys files on both the jump host and the target host, SSH will automatically use the key for authentication when using the -J parameter, without needing to manually enter a password. For example:

ssh -J user@jump-server.dealiaxy.com:10023 -i /path/to/private_key user@target.dealiaxy.com

This way, you can achieve a completely passwordless connection, further improving login efficiency.

4. Using ProxyJump in Configuration Files

If you don't want to manually enter the jump host's address and port every time on the command line, you can write the -J configuration into the SSH configuration file ~/.ssh/config. This allows you to set convenient aliases and configurations for different servers, avoiding repetitive input.

In the ~/.ssh/config file, you can configure it like this:

Host target-server
  HostName target.dealiaxy.com
  User user
  ProxyJump user@jump-server.dealiaxy.com:10023

After the configuration is complete, you only need to execute the following command:

ssh target-server

SSH will automatically connect first to the jump host jump-server.dealiaxy.com based on the ProxyJump parameter in the configuration file, and then forward to the target server target.dealiaxy.com.

5. Advantages

• Concise and Efficient: The -J parameter lets the SSH client automatically handle the connection and forwarding through the jump host, avoiding manually entering two commands.
• Supports Passwordless Authentication: Configuring SSH key pairs enables passwordless authentication, further boosting efficiency.
• Flexible Configuration: The ~/.ssh/config file can be used to set jump host configurations for multiple target hosts, simplifying management.

---

This is the basic method for simplifying SSH jump host connections using the -J parameter (ProxyJump). It not only improves work efficiency but also avoids the hassle of manually entering multiple passwords or commands. If your SSH version supports the -J parameter, this is undoubtedly the simplest and most direct solution.

Method 2: Using ProxyCommand

Before OpenSSH 7.3, the -J option didn't exist, and the SSH client didn't have a simple, direct way to support jump servers. However, we can achieve similar functionality using ProxyCommand. This method offers better compatibility compared to -J, making it suitable for older SSH client versions or situations where the -J parameter isn't supported.

ProxyCommand allows us to specify a command to use for the jump server connection, typically utilizing the nc (netcat) command. With this approach, when connecting to a target host, the SSH client first establishes a proxy connection to the jump server and then forwards the data stream through that proxy connection.

1. Basic Syntax

The basic syntax for using ProxyCommand in the SSH configuration file is as follows:

Host <target-host>
  ProxyCommand ssh -q -W %h:%p <jump-user>@<jump-host> -p <port>

• <target-host>: The address of the target host (can be a domain name or IP).
• <jump-user>: The username for the jump server.
• <jump-host>: The address of the jump server (can be a domain name or IP).
• <port>: The port of the jump server (default is 22; specify if using a custom port).
• %h and %p: Represent the hostname and port of the target host. SSH automatically substitutes these values at connection time.

2. Configuration Example

To set up access to a target host via a jump server, you can add the following configuration to your SSH client's config file (~/.ssh/config):

Host target.dealiaxy.com
  ProxyCommand ssh -q -W %h:%p user@jump-server.dealiaxy.com -p 10023

This configuration means that every time you attempt to connect to target.dealiaxy.com, the SSH client will first establish a connection through the jump server jump-server.dealiaxy.com (on port 10023), and then forward the traffic from the jump server to the target server.

3. Simplified Command After Configuration

Once ProxyCommand is configured, you no longer need to specify the jump server and port on the command line. You just need to run:

ssh user@target.dealiaxy.com

The SSH client will automatically connect to the jump server using the ProxyCommand configuration and forward the connection to the target host target.dealiaxy.com. The entire process requires no manual specification of any jump server parameters.

4. Configuration Flexibility

When using ProxyCommand, the flexibility of the configuration file allows us to configure different jump servers for different target hosts. If you have multiple internal network target hosts, you can add different configurations for each:

Host target1.dealiaxy.com
  ProxyCommand ssh -q -W %h:%p user@jump-server.dealiaxy.com -p 10023

Host target2.dealiaxy.com
  ProxyCommand ssh -q -W %h:%p user@jump-server.dealiaxy.com -p 10023

This way, when accessing different targets, you simply enter the corresponding hostname (e.g., ssh user@target1.dealiaxy.com), and the SSH client will automatically select the jump server based on the configuration to establish the connection.

5. Summary

ProxyCommand provides a flexible and highly compatible way to help us achieve the functionality of connecting to target servers via a jump server in SSH clients that do not support the -J parameter. Although this method is slightly more complex, it remains a very effective solution, especially suitable for users who need to operate across multiple environments.

---

By using this method, you can easily connect from your local machine to the target server via a jump server without logging in manually twice, saving time and increasing efficiency. If you are using an older version of the OpenSSH client, ProxyCommand is undoubtedly an excellent alternative.

Advanced: SSH Key Management / Multiple Jump Servers

When using SSH connections, it is generally recommended to authenticate using SSH key pairs rather than passwords. This not only enhances security but also eliminates the inconvenience of manually entering a password each time you log in. Furthermore, when dealing with multiple jump servers or requiring more complex SSH configurations, we can further simplify the connection process through some advanced settings.

1. SSH Key Management

SSH key authentication is a more secure and convenient method of authentication. Compared to password authentication, key authentication has clear advantages in the following aspects:

• Higher Security: Passwords can be guessed or cracked by brute force, while SSH keys are generated using encryption algorithms, making them much harder to crack.
• Passwordless Login: After configuring the public-private key pair, users can automatically complete login without entering a password.

Step 1: Generate an SSH Key Pair

If you don't already have an SSH key pair, you can generate one using the following command:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

This will generate a pair of public (id_rsa.pub) and private (id_rsa) keys in the ~/.ssh/ directory. During the generation process, you can set the key filename and a passphrase (optional).

Step 2: Copy the Public Key to the Jump Server and Target Host

To make key authentication work, we need to copy the public key to the ~/.ssh/authorized_keys file on both the target host and the jump server. You can use the ssh-copy-id command to automate this process:

ssh-copy-id -i ~/.ssh/id_rsa.pub user@jump-server.dealiaxy.com
ssh-copy-id -i ~/.ssh/id_rsa.pub user@target.dealiaxy.com

After executing these two commands, you will be able to log in without a password using your SSH key pair.

2. Configuration of Multiple Jump Servers

Sometimes, we need to pass through multiple jump servers (Multi-hop) to access the target server. In such cases, we can continue using the ProxyCommand or -J parameter to configure multiple jump servers.

2.1 Using the -J Parameter for Multi-hop Configuration

Assume we need to access the target server through two jump servers: the first jump server jump1.dealiaxy.com and the second jump server jump2.dealiaxy.com. The following command can be used:

ssh -J user@jump1.dealiaxy.com:10023 -J user@jump2.dealiaxy.com:10023 user@target.dealiaxy.com

In this command, the SSH client first connects to jump1.dealiaxy.com, then forwards the connection from jump1 to jump2.dealiaxy.com, and finally forwards it through jump2 to the target server target.dealiaxy.com.

2.2 Using ProxyCommand for Multi-hop Configuration

If we are using an older version of the SSH client or prefer to manually configure the SSH client settings, we can set ProxyCommand for multiple jump servers in the SSH configuration file (~/.ssh/config). An example is shown below:

Host target.dealiaxy.com
  ProxyCommand ssh -q -W %h:%p user@jump1.dealiaxy.com -p 10023
  ProxyCommand ssh -q -W %h:%p user@jump2.dealiaxy.com -p 10023

In this configuration, the SSH client first establishes a connection through jump1.dealiaxy.com, and then forwards the traffic to the target host target.dealiaxy.com through jump2.dealiaxy.com.

3. Configuring Keys for Multiple Target Hosts

If you have multiple target hosts and each uses a different SSH key for authentication, you can configure distinct keys for each host. You can use the IdentityFile parameter to specify different private key files. For example, in the SSH configuration file, you can set a different SSH key for each host:

Host target1.dealiaxy.com
  IdentityFile ~/.ssh/id_rsa_target1

Host target2.dealiaxy.com
  IdentityFile ~/.ssh/id_rsa_target2

This way, when you connect to target1.dealiaxy.com or target2.dealiaxy.com, the SSH client will automatically use the corresponding private key for authentication.

4. Optimizing Connection Speed: Using ControlMaster

During the connection process, each connection to the jump server and the target host involves establishing a new SSH session. To improve efficiency and reduce connection latency, we can utilize the SSH ControlMaster feature to accelerate subsequent connections by reusing existing SSH sessions. You can add the following configuration to your SSH configuration file:

Host jump-server.dealiaxy.com
  ControlMaster auto
  ControlPath ~/.ssh/cm_socket/%r@%h:%p
  ControlPersist 10m

Host target.dealiaxy.com
  ControlMaster auto
  ControlPath ~/.ssh/cm_socket/%r@%h:%p
  ControlPersist 10m

In this configuration, SSH will keep the connections to the jump server and the target host active in the background (for up to 10 minutes). If you reconnect within this time, SSH will directly reuse the existing connection, significantly reducing the time needed to establish a new connection.