ssh -L 10000:theprotectedserver.com:9042 [email protected]
This will open a shell to allow me to execute commands remotely on thebastionhost.com from my local machine. If any such command issues a network request (to any server?) on outgoing port 10000, the request will be forwarded to theprotectedserver.com:9042.
That's confused but mostly wrong.
In fact, this creates a secure (encrypted and authenticated) connection to thebastionhost and requests sshd (the server end of the connection) to run a shell on thebastionhost after which it relays anything you input on your terminal to that shell (or a program under it), and anything output by that shell (or a program under it) back to your terminal. (More exactly it creates a PTY or pseudo-terminal on thebastionhost and runs a shell on that PTY, and then relays input to and output from the PTY; coordination of I/O on the PTY by the shell and any other program(s) is handled by the PTY in the same fashion as a local terminal on thebastionhost.) This continues until the remote shell exits -- usually because you told it to, with exit or control+D or similar, but it could be due to a failure or shutdown -- or you command the local ssh to disconnect (standardly squiggle,period; this is rarely used) or the local process or system is killed or dies.
It also listens locally on port 10000, and if any process (call it P) on your local/client system opens that port, ssh requests sshd to open theprotectedserver:9042 from thebastionhost and (if successful) it relays anything sent by P over the 'tunnel' to that open and anything from that open back over the tunnel to P. This allows P to talk to whatever program is located on theprotectedserver:9042 (which could be anything) as if P was located on thebastionhost. Note that if you want to explicitly run P you must go to another terminal (or pseudoterminal like a window in tmux). OTOH if anyone else is logged-on to your client system, they can run P without your involvement or knowledge.
Both of these (your interaction with the remote shell, and P's interaction with whatever) occur concurrently and separately even though they are multiplexed over the single secure connection. In fact there can be multiple Ps each with its own connection to whatever is at theprotectedhost:9042 as long as that accepts such multiple connections at the TCP/IP level; most though not all TCP/IP servers or service applications do so.
ssh -N -L 10000:theprotectedserver.com:9042 [email protected]
This creates the secure connection but then skips all the rest of my first paragraph: it does not run a remote shell or relay data to and from it. In fact it ignores any input you try to give it. However, if you add & at the end -- or (assuming POSIX job control) you type control+Z and then the command bg -- the ssh is left running in the background and you can continue to give commands to your local shell. However the second para does happen, so you might use your local shell to run a P that accesses local port 10000 and gets relayed to theprotectedhost:9042 exactly as above except that this time you didn't need a different (local) terminal (or user).
