I would like to clarify Brian:s answer about Hamachi, with a Linux focus.
First install it:
wget https://secure.logmein.com/labs/logmein-hamachi_2.0.1.13-1_i386.deb
sudo aptitude install lsb
sudo dpkg -i logmein-hamachi_2.0.1.13-1_i386.deb
Then go to the hamachi page and create a new mash network, remember the "network-number" since the do-login needs it.
Back to the command line
sudo hamachi login
sudo hamachi set-nick $HOSTNAME
sudo hamachi do-join XXX-XXX-XXX
Then back to the webpage again and allow the clients to be on this network.
(maybe need to have the client to login again)
Then check what pc is on the network:
sudo hamachi list
Now you can grab that ip-number and ssh directly regardless if there is a NAT in the way!
/Have fun
youatwork@officepc$ autossh -R 12345:localhost:22 notroot@serverpc
Later:
you@homepc$ autossh -L 23456:localhost:12345 notroot@serverpc
you@homepc$ ssh youatwork@localhost -p 23456
What you could do is this: in step 1 forward a remote port from the office PC to the server (12345 is used as an example, any port >1024 should do). Now connecting to 12345 on the server should connect you to port 22 on officepc.
In step 2, forward the port 23456 from your home machine to 12345 on the server (whence it gets forwarded to officepc:22, as set up in step 1)
In step 3, you connect to the local port 23456 with your office PC login. This is forwarded by step 2 to port 12345 on your server, and by step 1 to your office PC.
Note that I'm using autossh for the forwardings, as it's a ssh wrapper which automatically reconnects the tunnel should it be disconnected; however normal ssh would work as well, as long as the connection doesn't drop.
There is a possible vulnerability: anyone who can connect to localhost:12345 on serverpc can now connect to officepc:22, and try to hack into it. (Note that if you're running a SSH server, you should anyway secure it above the basic protections which are on by default; I recommend at least disabling root login and disabling password authentication - see e.g. this)
Edit: I have verified this with the same config, and it works. GatewayPorts no only affects the ports that are open to the world at large, not local tunnels. This is what the forwarded ports are:
homepc:
outgoing ssh to serverpc:22
listening localhost:23456 forwarded through ssh tunnel
serverpc:
listening ssh at *:22
incoming localhost ssh tunnel (from homepc) forwarded to localhost:12345
listening localhost ssh tunnel (from officepc) forwarded from localhost:12345
officepc:
outgoing ssh to serverpc:22
incoming localhost through ssh tunnel (from serverpc) forwarded to localhost:22
So, as far as the network stack is concerned, it's all local traffic on the respective loopback interfaces (plus ssh connections to serverpc); therefore, GatewayPorts is not checked at all.
There is, however, the directive AllowTcpForwarding: if that is no, this setup will fail as no forwarding is allowed at all, not even across the loopback interface.
Caveats:
if using autossh and recent ssh, you may want to use ssh's ServerAliveInterval and ServerAliveCountMax for keeping the tunnel up. Autossh has a built-in check, but apparently it has some issues on Fedora. -M0 disables that, and -oServerAliveInterval=20 -oServerAliveCountMax=3 checks if the connection is up - tries each 20 sec, if it fails 3x in a row, stops ssh (and autossh makes a new one):
autossh -M0 -R 12345:localhost:22 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
autossh -M0 -L 23456:localhost:12345 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
it might be useful to restart ssh tunnel if the forward fails, using -oExitOnForwardFailure=yes - if the port is already bound, you might get a working SSH connection, but no forwarded tunnel.
using ~/.ssh/config for the options (and ports) is advisable, else the command lines get too verbose. For example:
Host fwdserverpc
Hostname serverpc
User notroot
ServerAliveInterval 20
ServerAliveCountMax 3
ExitOnForwardFailure yes
LocalForward 23456 localhost:12345
Then you can use just the server alias:
autossh -M0 fwdserverpc
Best Answer
OK, lets try to clarify the relevant terms.
Public IP
Everybody with an internet connection has a "public IP" that is an IP-address which is visible to the general public.
This public IP-address is sometimes referred to as an external IP-address. It is usually allocated to your router by your ISP.
It can be dynamic or static. Some ISPs charge more for a static addrsss. Dynamic ones are allocated from a pools, in this case your public IP-address can change from time to time
NAT
Traditional IP addresses are IP version 4 addresses. These are running out. To stave-off address exhaustion, some ranges were reserved for private use (e.g. 192.168.0.0) and Network Address Translation (NAT) was invented so that a router could edit (translate) addresses in IP packets and change a private IP-address to a public one. That way a business or home with tens or thousands of computers could all share a single public IP-address.
So yes, most people have a public IP-address and are behind NAT.
Outbound connections
TCP connections are started by a client sending a packet to a server (as part of a "three-way handshake"). The router sees this packet, edits the from-address and keeps a note in an internal list of connections of the internal source IP-address, source port and translated source port (it has to cope with two PCs both using the same source port getting their source IP-address translated to the same public IP-address). Since it keeps track of connections, when the router receives reply packets it can work out which internal PC to forward the (edited) packets on to.
So no, replies to an outbound SSH connection should not be blocked.
connections initiated from the outside are a different matter:
Inbound connections
When the router receives an inbound request to create a connection on a specific port (e.g. 80) - if it doesn't provide a service on that port itself (e.g. router admin interface) it won't know what to do and will refuse the connection.
Port forwarding
If you want friends, random strangers (and criminals) to have access to your PC, you can tell the router that when it receives a connection request on port n to forward that request to one of your computers.