June 7, 2013
Scenario: you want to allow Fred SSH access to your local machine and, for whatever reason, cannot expose your local SSH port to the public Internet.
+----------------+ | | | Yourbox | | | +----------------+
You can establish a reverse SSH tunnel to a remote machine (a “jumphost”) that can expose its local SSH port to the Internet.
A. SSH to jumphost with a reverse tunnel pointing jumphost’s port 1234 back to your port 22.
Yourbox$ ssh -R 1234:localhost:22 you@jumphost
+----------------+
| |
| Yourbox |
| |
+----------------+
|
|
A |
|
\|/
+----------------+
| |
| Jumphost |
| |
+----------------+
B. Have Fred SSH into jumphost.
Fredbox$ ssh you@jumphost
+----------------+
| |
| Yourbox |
| |
+----------------+
|
|
A |
|
\|/
+----------------+
| |
| Jumphost |
| |
+----------------+
/|\
|
| B
|
|
+----------------+
| |
| Fredbox |
| |
+----------------+
Fred can then use that reverse SSH tunnel to access your local machine.
C. On Jumphost, Fred SSHs to the local port 1234, which is then forwarded over the tunnel to yourbox.
Jumphost$ ssh -p 1234 you@localhost
+----------------+
| |
| Yourbox |
| |
+----------------+
| /|\
| |
A | | C
| |
\|/ |
+----------------+
| |
| Jumphost |
| |
+----------------+
/|\
|
| B
|
|
+----------------+
| |
| Fredbox |
| |
+----------------+
I’ve referenced the you user account here for illustrative purposes, but rather than handing out that account’s password, putting Fred’s SSH pubkey into your ~/.ssh/authorized_keys for the duration of the session would be more convenient for everybody.