SFTP: Pull Files from Remote Host Without Directly Knowing

You can pull files from a remote SFTP server without knowing its direct hostname or IP address by establishing an SSH tunnel through an intermediate "jump host" that has network access to both your local machine and the target server. This method leverages the -J (ProxyJump) flag in modern OpenSSH clients, allowing you to route traffic securely through a known gateway. Alternatively, older configurations use the -W option for manual port forwarding within the SSH configuration file, enabling transparent access to internal resources behind firewalls or in DMZs.

The Concept of Proxy Jumping

In secure infrastructure, direct connections to servers located in Demilitarized Zones (DMZs) or private subnets are often blocked by firewalls to prevent unauthorized external access. However, administrators typically maintain access to a bastion host or jump box that sits on the perimeter. The goal is to make the client believe it is connecting directly to the final destination, while the SSH client automatically handles the hop-through logic. This technique eliminates the need to manually open local ports and manage complex netcat or socat pipes. Instead, the SSH protocol itself manages the connection chain. When you configure a proxy jump, the SSH client first authenticates with the intermediate server. Once that session is established, it forwards the data stream destined for the final SFTP server back through that same encrypted channel. This ensures that all data remains encrypted end-to-end, even though it traverses multiple network hops. For users who have already configured passwordless authentication, such as those following guides on SSH Host RSA Key Configuration for Passwordless SFTP, this process becomes seamless. You do not need to enter passwords twice; if your keys are set up correctly, the client will handle both authentication steps silently in the background.

Using the -J Flag for Quick Access

The most straightforward way to achieve this connectivity is using the ProxyJump directive available in OpenSSH 7.3 and later versions. This approach requires no changes to your global configuration files and works well for ad-hoc connections or scripts where you want explicit control over the command line. To pull files using this method, you specify the jump host immediately after the -J flag, followed by the username and hostname of the actual target SFTP server. The syntax follows a specific order: the jump host comes first, then a comma, and finally the destination.

ssh -J [email protected] [email protected]

Once the shell session is established on the target server, you can exit and return to the SFTP prompt. To transfer files, invoke the SFTP client with the same structure:

sftp -J [email protected] [email protected]

Inside the SFTP session, you can use standard commands like get to download files or put to upload them. The client treats the connection as if it were local, abstracting away the complexity of the network topology. If you encounter connection issues, ensure that the jump host allows TCP forwarding, which is usually enabled by default but can be restricted by AllowTcpForwarding no in the server's sshd_config.

Configuring SSH Config for Persistent Access

While command-line flags are convenient, defining these routes in your local ~/.ssh/config file provides a more robust solution for frequent operations. By creating aliases, you simplify future commands and reduce the risk of typos. This method is particularly useful when dealing with multiple jump hosts or when you need to apply specific options like compression or cipher preferences to the chain.

Add the following block to your ~/.ssh/config file:

Host sftp-target
    HostName sftp-target.internal.net
    User myuser
    ProxyJump [email protected]


After saving the file, you can connect simply by typing sftp sftp-target. The SSH client reads the ProxyJump directive and automatically establishes the necessary tunnel. This approach also allows you to store different credentials for the jump host and the target server separately, enhancing security by keeping sensitive details organized.

If you are migrating from older systems or using legacy clients that do not support ProxyJump, you can use the -W option. This stands for "standard input/output" and tells SSH to forward all local standard I/O to the remote host. The configuration would look like this:

Host sftp-target-legacy
    HostName sftp-target.internal.net
    User myuser
    ProxyCommand ssh -W %h:%p [email protected]


This method achieves the same result but relies on the older proxy command syntax. It is important to note that -W is generally slower than -J because it does not optimize the multiplexing of the connection as effectively. For new deployments, always prefer the ProxyJump method.

Troubleshooting Connection Issues

When setting up indirect SFTP connections, several common pitfalls can prevent successful transfers. One frequent issue arises from firewall rules that block outbound connections from the jump host to the target server's port 22. Ensure that the network security groups or ACLs associated with the jump host explicitly allow traffic to the target IP on the SSH port.

Another potential problem involves DNS resolution. Since the target hostname might only resolve internally within the network segment behind the jump host, your local machine may fail to resolve the name. In such cases, using the IP address in the HostName field of your SSH config is necessary, while relying on the jump host to perform the DNS lookup for the internal domain.

If you receive permission denied errors, verify that your SSH keys are present on both the local machine and the jump host. The jump host must trust your key to initiate the second leg of the journey. Additionally, check the logs on the jump host (/var/log/auth.log on Debian-based systems) to see if the connection attempt from the jump host to the target was rejected due to PAM restrictions or user limits. For deeper insights into authentication failures, reviewing articles on Troubleshooting SFTP User Connection Error in Debian 11 can provide context on system-level blocks.

Frequently Asked Questions

Can I use this method with non-SSH protocols?
No, ProxyJump and SSH tunneling rely entirely on the SSH protocol being available on the intermediate and target servers. If the target SFTP server runs on a non-standard port, you must specify it in the HostName or use the -P flag, but the underlying transport must still be SSH. For other protocols like FTP or HTTP, you would need a different type of proxy or VPN solution.

Does ProxyJump affect file transfer speed?
There is a slight overhead due to the extra encryption layer and network hop, but it is usually negligible for typical file sizes. The primary bottleneck is often the bandwidth of the link between your local machine and the jump host, rather than the internal network latency. Compressing data with -C can sometimes help if the connection to the jump host is slow.

What happens if the jump host goes down?
The connection will fail immediately, as the jump host is a critical dependency for establishing the tunnel. Unlike some load-balanced services, there is no automatic failover unless you have configured high availability for the jump host itself. You should monitor the uptime of the jump host closely if it is a single point of failure for your remote access workflows.

Is it safe to store jump host credentials in SSH config?
It is safe as long as you restrict the file permissions of ~/.ssh/config to 600, ensuring only your user account can read it. Storing keys in the config file is not recommended; instead, use the IdentityFile directive to point to existing key pairs. This keeps your credentials separate from the connection logic and reduces the risk of accidental exposure.

How do I debug the connection process?
Use the -v (verbose) flag with your SSH or SFTP command to see detailed logging of each step. Adding multiple vs (e.g., -vvv) provides even more granular information about key exchanges and authentication attempts. This output helps identify whether the failure occurs at the jump host authentication stage or during the forwarding to the target server.