Proxyjump, the SSH option you probably never heard of

Today, it is becoming more and more common for Penetration Testers, Security Researchers, Red Teams, and the like to require some sort of tunneling in and out of an organization’s infrastructure. Internal Red Teams, especially, who may need to cordon off their Command and Control Infrastructure will likely employ SSH (or VPN, but that will be a different post) tunnels from their External Infrastructure (such as callback servers, web hosting, mail, etc) to the Internal assets. Setting up these tunnels can become quite convoluted and difficult to manage, especially once the number of hops or jumps between servers increase.

Tunneling

Cascading SSH Tunnels can be a real pain in the hind-parts

For the purpose of this blog post, an environment as depicted below has been set up. The goal is to ensure beacons from the Victims can reach the teamserver host embedded deep in a corporate datacenter.

Historically, due to my own ignorance of advanced SSH options, I would attempt to manage these multiple tunnels by cascading each tunnel onto another:

To ensure beacons that hit the last-hop would be able to reach the internal team server, the multiple tunnel commands look like such:

[teamserver]
ssh -R 8080:127.0.0.1:80 internal-proxy -f -N[Int. Proxy Server]
ssh -R 8080:127.0.0.1:8080 external-proxy -f -N[Ext. Proxy Server ]
ssh -R 0.0.0.0:8080:127.0.0.1:8080 last-hop -f -N

After executing each of these respective commands, a simple web request demonstrates that the web request follows each of the tunnels all the way back to the teamserver.

Setting this up requires each of these commands to be run on their respective machines. Any changes, however, require killing the tunnel at each stop, and re-executing. The headache in practice-without some sort of management software running across each of the servers-becomes very apparent. An easier way to manage these tunnels must exist.

ProxyJump

Just like we found out last month about Aliens, ProxyJump is a real thing!

Enter [ProxyJump] , an SSH advanced option which is simply a simplification of ProxyCommand ( ProxyCommand ssh proxy-host -W %h:%p ). ProxyJump allows for an SSH tunnel to pivot through one SSH host (proxy) to another. The ProxyJump option can be invoked by -J on the commandline:

ssh -J internal-proxy last-hop -f -N

My personal preference is using an SSH config ( /home/user/.ssh/config ) and SSH keys (if not, you would be prompted for a password to login to each ProxyJump hop). Here, a single hop can be specified as such to SSH :

Host internal-proxy
    HostName 10.20.30.253
    Port 22
    User nopriv
    IdentityFile /home/nopriv/.ssh/id_rsa
Host last-hop
    HostName 10.100.2.240
    Port 22
    User nopriv
    IdentityFile /home/nopriv/.ssh/id_rsa
    ProxyJump internal-proxy

Saving the example above and executing the ssh command ssh last-hop, the prompt of last-hop is presented (with netstat output) below. The internal-proxy is seen connected over TCP port 22 vice the teamserver itself.

Ok, so what about multiple proxies? As referenced [here] , one must simply chain the proxies in the order from closest to farthest from the teamserver in the SSH config:

Host internal-proxy
    HostName 10.20.30.253
    Port 22
    User nopriv
    IdentityFile /home/nopriv/.ssh/id_rsa
Host external-proxy
    HostName 10.100.2.200
    Port 22
    User nopriv
    IdentityFile /home/nopriv/.ssh/id_rsa
    ProxyJump internal-proxy
Host next-hop
    HostName 10.100.2.210
    Port 22
    User nopriv
    IdentityFile /home/nopriv/.ssh/id_rsa
    ProxyJump external-proxy
Host last-hop
    HostName 10.100.2.240
    Port 22
    User nopriv
    IdentityFile /home/nopriv/.ssh/id_rsa
    ProxyJump next-hop

Executing ssh last-hop , and running netstat from last-hop, it is shown that next-hop is the only system connected over TCP port 22 to last-hop :

So how does this help tunneling port forwards? Well, simply adding the line RemoteForward 8080 127.0.0.1:80 at the end of the SSH config will setup the remote port forward:

Host last-hop
    HostName 10.100.2.240
    Port 22
    User nopriv
    IdentityFile /home/nopriv/.ssh/id_rsa
    ProxyJump next-hop
RemoteForward 8080 127.0.0.1:80

After saving the config and executing this time ( ssh last-hop) , a quick netstat on last-hop shows that 8080 is now bound. Also, using curl to request last-hop:8080 shows that the tunnel is indeed forwarding back any requests from last-hop through next-hop, external-proxy, and internal-proxy to teamserver on port 80:

If different jump hosts use separate identity files, the user and identity file just need to match their respective host in the config. For example, in our demo config, we will use user2 as an identity on the internal-proxy and nopriv on the last-hop:

Host internal-proxy
    HostName 10.20.30.253
    Port 22
    User user2
    IdentityFile /home/nopriv/.ssh/user2
[…]
Host last-hop
    HostName 10.100.2.240
    Port 22
    User nopriv
    IdentityFile /home/nopriv/.ssh/id_rsa
    ProxyJump internal-proxy

Executing our ssh command ssh last-hop , presents a successful login at last-hop through the internal-proxy, external-proxy , and next-hop :

The key exchange with internal-proxy verifies the user2 credentials were used in the authentication:

Conclusion

In summary, ProxyJump is an easy way to manage SSH tunnels across proxies, extending services that may be buried in a corporate data center or in the cloud to where you need them. The use of ProxyJump minimizes the number of separate tunnels required and when coupled SSH configs, modification of such tunnels are quite simple and quick.