I love explaining this kind of thing through visualization. :-)
Think of your SSH connections as tubes. Big tubes. Normally, you'll reach through these tubes to run a shell on a remote computer. The shell runs in a virtual terminal (tty) through that tube. But you know this part already.
Think of your tunnel as another tube within a tube. You still have the big SSH connection, but the -L or -R option lets you set up a smaller tube inside it.
Your ssh remote shell actually communicates with you using one of these smaller, embedded tubes attached to stdio.
Every tube has a beginning and an end. The big tube, your SSH connection, started with your SSH client and ends up at the SSH server you connected to. All the smaller tubes have the same endpoints, except that the role of "start" or "end" is determined by whether you used -L or -R (respectively) to create them.
(You haven't said, but I'm going to assume that the "remote" machine you've mentioned, the one behind the firewall, can access the Internet using Network Address Translation (NAT). This is kind of important, so please correct this assumption if it is false.)
When you create a tunnel, you specify an address and port on which it will answer (or "bind"), and an address and port to which it will be delivered. The -L option tells the tunnel to bind on the local side of the tunnel (the host running your client). The -R option tells the tunnel to bind on the remote side (the SSH server).
So... To be able to SSH from the Internet into a host behind a firewall, you need the target host to open an SSH connection to a host on the outside and include a -R tunnel whose "entry" point is the "remote" side of its connection.
Of the two models shown above, you want the one on the right.
From the firewalled host:
ssh -f -N -T -R22222:localhost:22 yourpublichost.example.com
This tells the client on your target host to establish a tunnel with a -Remote entry point. Anything that attaches to port 22222 on the far end of the tunnel will actually reach "localhost port 22", where "localhost" is from the perspective of the exit point of the tunnel (i.e. your ssh client in this case, on the target host).
The other options are:
-f tells ssh to background itself after it authenticates, so you don't have to sit around running something like sleep on the remote server for the tunnel to remain alive.-N says that you want an SSH connection, but you don't actually want to run any remote commands. If all you're creating is a tunnel, then including this option saves resources.-T disables pseudo-tty allocation, which is appropriate because you're not trying to create an interactive shell.
There will be a password challenge unless you have set up a key for a passwordless login.
(Note that if you intend to leave a connection open long term, unattended, possibly having it automatically refresh the connection when it goes down (by parsing ssh -O check <remotehost>), I recommend using a separate, unique SSH key for it that you set up for just this tunnel/customer/server, especially if you are using RemoteForward. Trust no one.)
Now that the -R service tunnel is active, you can connect to it from yourpublichost, establish a connection to the firewalled host through the tunnel:
ssh -p 22222 username@localhost
You'll get a host key challenge, as you've probably never hit this host before. Then you'll get a password challenge for the username account (unless you've set up keys for passwordless login).
If you're going to be accessing this host on a regular basis, you can also simplify access by adding a few lines to your ~/.ssh/config file on yourpublichost:
host firewalledhost
User firewalleduser
Hostname localhost
Port 22222
Adjust firewalledhost and firewalleduser to suit. The firewalleduser field must match your username on the remote server, but firewalledhost can be any name that suits you, the name doesn't have to match anything resolvable, since your connection is governed by Hostname and Port.
Alternately, if you want to reach this from elsewhere on the Internet, you might add the following to your ~/.ssh/config:
host firewalledhost
ProxyCommand ssh -fWlocalhost:22222 yourpublichost
The -W option is used to open a connection to a remote host in order to continue the SSH conversation. It implies -N and -T.
See also:
