Effectively, your browser's network connections will now seem to originate from the netadmins' workstation, while the browser (and any associated Java applets) will still be run fully locally, with minimum latency.Īnd so you can access the Java-based web GUI of that pesky old router remotely with a somewhat tolerable level of latency. Laptop$ ssh -D 1234 as long as that SSH connection is up, you can fire up a local browser, configure it to use a SOCKS proxy located at localhost:1234 and all the outgoing network connections from that browser will go out through the SSH connection to the netadmins' workstation, and from there on as regular TCP connections to whatever address specified in the browser. Through the company VPN, you can access the network administrators' workstation remotely, but you know from experience that using X11 forwarding to run a remote browser is painfully slow. You're hundreds of miles away from the server room. You're on a well-earned vacation, when the big boss calls and tells you that the your stand-in is sick from food poisoning and some old router in the server room needs to be rebooted ASAP. Of course the network administrators' workstation runs Linux :-) This workstation has two NICs: one to the regular network, and another to the remote console segment, but it is intentionally configured to not act as a router. Since those aren't always updateable to the latest TLS standards, you've connected them to a strictly local network segment that is accessible through a particular network administrators' workstation only. You might have a server room full of equipment with web-based remote console functionality. A dynamic port forwarding (option -D in OpenSSH) does just that, supporting the SOCKS4 and SOCKS5 protocols. In both cases, both the SSH client and the sshd daemon work together to implement the functionality, but whichever is accepting the incoming connections could be said to act as a proxy for the actual service on the opposite side of the SSH connection.Ģ.) Also yes, but then the request must be specified using a protocol that is understood by SSH. And if you specify a remote port forwarding (option -R in OpenSSH), the sshd daemon at the remote end will act as a proxy that forwards connections incoming to a a specified remote port/socket to the specified target on the local side of the SSH connection. 1.) Yes: if you specify a local port forwarding (option -L in OpenSSH), your SSH client will act as a proxy that forwards the connection that's incoming to a specified local port/socket onto a specified target at the remote end of the SSH connection.
0 Comments
Leave a Reply. |