Multi-Hop Access

Connecting to machines behind firewalls.

It’s common for large computing environments to restrict SSH access from outside the network. Drexel implements this — you cannot connect to arbitrary Drexel computers from outside the Drexel network. Such environments, including Drexel, usually provide two mechanisms for external remote access:

When using a VPN, everything should work just like it does on the real network.

When using a bastion host (at Drexel, tux.cs.drexel.edu is a bastion host), you need to make a multi-hop connection. You first connect to Tux, and then connect from Tux to wherever you are looking to connect.

For SSH terminal sessions, this isn’t too bad: you run ssh on your machine to connect to Tux, and then run ssh on Tux to connect to the machine you really want to talk to.

For other SSH services, like VS Code remote editing or copying files, that doesn’t work very well. Fortunately, SSH is built to handle bastion host setups, and we can configure them automatically using a feature called ProxyJump. We can edit ~/.ssh/config to use a jump host (bastion host) for specific remote systems:

Host mylab.cci.drexel.edu
    ProxyJump tux.cs.drexel.edu

With this in place, if we run ssh mylab.cci.drexel.edu, it will make two connections: it will first connect to tux, and then use tux to connect to mylab, and set it up so that it is the same as if we directly connected to mylab in terms of port forwards and other features. If you are using password authentication, you will need to enter your password twice.

VS Code also respects these settings (since it uses the standard OpenSSH software), so you can use ProxyJump to configure hosts to allow remote editing sessions too.

Using ProxyJump can be slightly slower and more brittle than using the VPN, but it works pretty well.

Many graphical SSH tools, such as ShellFish or MobaXTerm, also provide support for jump hosts or bastion hosts.