![]() 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. OTOH if anyone else is logged-on to your client system, they can run P without your involvement or knowledge.īoth 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. Note that if you want to explicitly run P you must go to another terminal (or pseudoterminal like a window in tmux). This allows P to talk to whatever program is located on theprotectedserver:9042 (which could be anything) as if P was located on thebastionhost. 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. (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. 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. If any such command issues a network request (to any server?) on outgoing port 10000, the request will be forwarded to :9042. Ssh -L 10000::9042 will open a shell to allow me to execute commands remotely on from my local machine. Can someone explain what is going on here with a little more detail? I guess this is confusing to me because of the fact the command is executed on my machine, but the network part is decoupled and gets routed to the bastion host. So this SSH session ssh -N -L 10000::9042 now cause the commands to be executed locally on my physical machine, instead of remotely on ? But somehow, any network requests that go to port 10000 will still be routed through the on to :9042 ? This is useful for just forwarding ports (protocol version 2 only). Now, assuming this is correct, let's discuss adding -N which according to the docs: I am new to SSH tunneling and I am trying to understand how -L works in conjunction with -N.įirst, let me confirm my understanding of local SSH tunnel by itself: ssh -L 10000::9042 will open a shell to allow me to execute commands remotely on from my local machine.
0 Comments
Leave a Reply. |