I've looked at reverse ssh tunnelling, but I think what most people really want is ppp-over-ssh.  Reverse ssh tunnelling presupposes that the firewalling allows ports like 19999 through.  In many cases it's going to be better to go exclusively through whatever port is being used for ssh, 22 or otherwise.  An example of ppp-over-ssh would be:

 sudo /usr/sbin/pppd updetach pty \
"sudo ssh 138.47.99.99 sudo /usr/sbin/pppd notty 192.168.254.254:192.168.254.253"

which provides a ppp0 interface on each of the two machines.

--Fred Feirtag

Nothing to do on the iPhone. Most jailbreaks include OpenSSH or you can download (Cydia) OpenSSH onto your iPhone.

 After joining iPhone to Mac over WiFi on unsecured 40-bit WEP connection. We write down the iPhones IP# (169.254.x.y) and then don't even touch the iPhone again, instead we just reverse proxy a secure (SSH) SOCKS proxy back into the iPhone and gain access to the internet through the now tethered iPhone. (No need for any Apple banned applications from the App Store)...

MacbookPro17$ ssh -ND 9999 root@169.254.x.y

I've changed my iPhone root password, but if you have not, the default password is Alpine (change it right away after your first SSH into your phone).

 Now on the MacbookPro17 laptop I just use localhost and port 9999 as the SOCKS proxy and a simple browse in iPhone Safari or checking of Mail will flip the iPhone into accessing the internet which is now wide open for use by the MacbookPro17 laptop to use.

 SSH, freeing the masses everywhere!

Those one liners are OK until multiple ports need to be opened.  A better way is to set it up in your ~/.ssh/config file:

Host remotehost
  Hostname remotehost.org
  User remoteuser
  HostKeyAlias remotehost
  ConnectionAttempts 3
  TCPKeepAlive no
  CheckHostIp no
  RemoteForward 20023 localhost:22
  RemoteForward 2221 lhost1:22
  RemoteForward 2222 lhost2:22
  RemoteForward 2389 lhost3:389
  RemoteForward 2390 lhost4:389
  RemoteForward 2391 lhost5:389
  RemoteForward 20080 lhost6:80
  RemoteForward 20443 lhost6:443
  LocalForward 3001 remotehost:3000
  LocalForward 8001 remotehost:8000
  ForwardAgent yes
  ForwardX11 yes
  Protocol 2

 What we have above is a two way tunneling: 

    - RemoteForward - reverse tunneling from the remote host to the source the tunnel is initiated from

   -  LocalForward - enabling reverse local foward to local system from a system that is behind a firewall we are making connection to.

 SSH tunneling is a blessing and a curse at the same time.  The blessing because I can walk around NAT and firewalls and a curse of all Network admins who want to keep their networks under tight control...

http://www.harding.motd.ca/autossh/

 I use this program for a remote printing setup.

I do a config for about 12 localhost ports that cups prints to and they goto the corresponding ip addresses at the branch office. I have multiple configs for each of our branches and its really a cheap way to do remote from server printing with out costly VPN hardware and problems.

Some like this for my dedicated user's $HOMEDIR/.ssh/config

Host remoteofficeprint1
HostName 123.123.123.123
        KeepAlive yes
        User roprint
        IdentityFile    ~roprint/.ssh/specialkey1
        LocalForward    9102    192.168.101.14:9100
        LocalForward    9103    192.168.103.22:9100
        LocalForward    9104    192.168.100.220:9100
        LocalForward    9105    192.168.101.229:9100
        LocalForward    9106    192.168.101.228:9100
        LocalForward    9107    192.168.101.225:9100
        LocalForward    9108    192.168.101.24:9100
        LocalForward    9109    192.168.101.15:9100
        LocalForward    9110    192.168.107.17:9100
        LocalForward    9111    192.168.103.60:9100
        LocalForward    9120    192.168.102.40:9100
        LocalForward    9127    192.168.101.221:9100

Then I use this command from a screen session (as roprint):

        autossh -M 17004 remoteofficeprint1

 of course there has to be a proper setup on the destination to accept the pubkey auth. Autossh keep the connection up, if it can connect and login the tunnel is UP, never down, except when there is a real traffic problem on the internet. Some of our tunnels are between continents, the simplicity of autossh is what makes its so great!

It could just as easily be used for reverse tunnels. And can be configured to run from an init process, so its even possible to do more stuff.

If you add to your /$HOME/.ssh/config the following directive TCPKeepAlive=yes or add an 'o'ption switch on the command line ssh -o TCPKeepAlive=yes

you'll be able to maintain your reverse tunnel connection.

Step 1

I recommand to use ssh option -f to detach ssh process from the tty and -N to not execute any command over ssh (the connexion is just used for port forwarding)

Using key authentication (option -i) is quite better too and make this command to be run within a boot script (like /etc/rc.local) :

ssh -i /path/to/priv/key/id_rsa -f -N -R 19999:localhost:22 sourceuser@138.47.99.99

Step 3

In your example, you have to give a shell access to 138.47.99.99 to a foreign user (bob) in order to let him connect to destination.

If bob does not need any shell access to 138.47.99.99, you can specify the remote port forwarder to listen on one specific interface or any (instead of 127.0.0.1 by default) :

ssh -i /path/to/priv/key/id_rsa -f -N -R *:19999:localhost:22 sourceuser@138.47.99.99

But take care this last command makes the destination UNIX system being exposed to Internet via 138.47.99.99. IP filtering and/or a knockd daemon are recommanded on 138.47.99.99 if you do not want an internal server being scanned.