SSH Jump Host: Access Server B via SSH from Server C

To access Server B from Server C using Server C as a jump host, you must configure SSH to tunnel through the local machine. This setup allows Server C to act as an intermediary, forwarding traffic to Server B. You achieve this by editing the SSH client configuration file on Server C to define the jump host and target server addresses.

Understanding the Jump Host Concept

A jump host, also known as a bastion host, is a secure server that provides access to other servers in a private network. In this scenario, Server C serves as the entry point. Since Server B is not directly reachable from your initial connection point, you use Server C to bridge the gap. The key requirement is that Server C must have network connectivity to both the source (wherever you are connecting from) and the destination (Server B). This method enhances security by limiting direct exposure of internal servers to the public internet.

Configuring the SSH Client on Server C

The most efficient way to set up this connection is by modifying the ~/.ssh/config file on Server C. This file allows you to define aliases and specific parameters for different hosts, eliminating the need to type long command-line arguments every time. You will create an entry for Server B that specifies Server C as the jump host. First, open the configuration file using a text editor like nano or vim. Then, add the following block:

Host server-b
    HostName addressB.internal
    User your_username
    ProxyJump addressC.internal

Host addressC.internal
    HostName addressC.internal
    User your_username

In this configuration, ProxyJump tells SSH to route the connection through addressC.internal before reaching server-b. The second block ensures that SSH knows how to connect to the jump host itself. Replace your_username with the actual user account on both servers. This setup assumes that both servers share compatible authentication methods, such as SSH keys.

Executing the Connection

Once the configuration is saved, you can initiate the session from Server C by simply running ssh server-b. SSH will automatically handle the multi-hop connection. It first connects to addressC.internal, authenticates, and then establishes a secondary connection to addressB.internal through that channel. If you prefer to use command-line flags instead of the config file, you can achieve the same result with:

ssh -J addressC.internal [email protected]

The -J flag stands for -proxyjump. It accepts a comma-separated list of jump hosts. For simple two-hop connections, this is very concise. However, for complex networks with multiple hops, the ~/.ssh/config approach is more maintainable and less prone to typing errors.

Troubleshooting Connectivity Issues

Even with correct configurations, you might encounter issues. Common problems include firewall restrictions, incorrect DNS resolution, or permission denied errors. If you receive a kex_exchange_identification error, it often indicates a network-level blockage or an SSH version mismatch between the jump host and the target. Check our guide on Troubleshooting kex_exchange_identification Error in Linux SSH Connection for detailed steps to resolve handshake failures. Another frequent issue is failing to authenticate on the jump host. Ensure that your SSH keys are correctly placed in ~/.ssh/id_rsa on Server C and that the corresponding public key is added to ~/.ssh/authorized_keys on both Server C and Server B. Verify permissions on these files; they should typically be 600 for private keys and 644 for authorized keys.

Using SCP and SFTP with Jump Hosts

File transfer tools like scp and sftp also respect the SSH configuration. You can copy files directly to Server B from Server C without manually logging into the jump host first. For example:

scp ./file.txt server-b:/home/user/

This command uses the same ProxyJump directive defined in your config. If you encounter errors related to file submission, ensure that your SSH agent is running and forwarding keys properly. Sometimes, agents fail to forward credentials across multiple hops, leading to silent authentication failures. Check our article on SSH X11 Forwarding Issues: Works for WSL but not Remote Host if you suspect broader SSH forwarding complications affecting your workflow.

Security Best Practices

Always restrict SSH access to the jump host using firewall rules. Only allow connections from trusted IP addresses or subnets. Additionally, consider using SSH certificates instead of standard keys for large-scale deployments, as they offer easier revocation and expiration management. Regularly audit the ~/.ssh/config files on all servers to ensure no unauthorized entries exist.

Frequently Asked Questions

Can I use a password instead of SSH keys?

Yes, you can use passwords, but you must enable password authentication on both the jump host and the target server. This is generally discouraged due to lower security standards compared to key-based authentication.

What if Server B has a different username than Server C?

You can specify different usernames for each host in the ~/.ssh/config file. Just update the User directive under the respective Host blocks to match the accounts on each server.

Does ProxyJump work with older versions of OpenSSH?

No, the ProxyJump option was introduced in OpenSSH 7.3. If you are using an older version, you must use the -W flag with nc or rely on the ProxyCommand directive for compatibility.

How do I verify the connection path?

Use the -v flag with SSH to enable verbose mode. This outputs detailed information about the connection process, including which hosts are being contacted and where authentication succeeds or fails.

Is it safe to store jump host details in ~/.ssh/config?

It is safe provided you set strict file permissions (600) on the config file. Never share this file publicly, as it reveals your network topology and server addresses to anyone who gains access to your account.