generated from HariSekhon/Template-Repo
-
Notifications
You must be signed in to change notification settings - Fork 18
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
46f9997
commit 17913ab
Showing
1 changed file
with
32 additions
and
7 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,22 +1,47 @@ | ||
# SSH Tunnelling | ||
|
||
## Generic SSH Port Forwarding | ||
|
||
SSH login to `host1` and bind local port number to forward through the ssh tunnel to `host2` on the specified port. | ||
|
||
```shell | ||
ssh -L <local_port>:<host2>:<host2_port> <user>@<host1> | ||
``` | ||
|
||
Then just connect to the localhost `127.0.0.1:<port>` so network packets sent to that local port will tunnel through | ||
SSH and be forwarded on the other side from the ssh server on that same port. | ||
|
||
WARNING: you probably don't want to use `-R` because that would bind the port on the remote `host1` in a way that | ||
anybody could connect to it - it wouldn't be protected inside an SSH tunnel on your local machine, and nor would | ||
your network packets between your machine and `host1`. | ||
|
||
##### Use Case Example | ||
|
||
I used to use this `-L` tunnel to my home Subversion server in the 2000s to commit my home directory configs and | ||
personal scripts for my l33t Gentoo workstation & laptop. Thankfully the superior [Git](git.md) and remote working both | ||
kill the need for such tunnelling just to commit. | ||
|
||
## HTTP Proxying | ||
|
||
See [HTTP Proxying](http-proxying.md). | ||
|
||
## GCP | ||
|
||
On GCP, you may tunnel through a proxy host like this: | ||
On GCP, you may tunnel through a bastion host like this: | ||
|
||
unsetting `HTTPS_PROXY` ensures `gcloud` commands can access the Google APIs (could also just move `NO_PROXY` higher up) | ||
(exclude `googleapis.com` otherwise `gcloud` CLI won't be able to connect to Google since it is the tunnel which is | ||
not up yet) | ||
|
||
```shell | ||
unset HTTPS_PROXY | ||
export no_proxy="googleapis.com" | ||
export NO_PROXY="$no_proxy" | ||
export PROJECT_PROXY_PORT=8888 | ||
|
||
gcloud compute ssh bastion-vm -- -4 -N \ | ||
-L "$PROJECT_PROXY_PORT:127.0.0.1:$PROJECT_PROXY_PORT" \ | ||
-o "ExitOnForwardFailure yes" \ | ||
-o "ServerAliveInterval 10" | ||
|
||
export HTTPS_PROXY="http://localhost:$PROJECT_PROXY_PORT" | ||
export NO_PROXY="googleapis.com" | ||
export https_proxy="http://localhost:$PROJECT_PROXY_PORT" | ||
export HTTPS_PROXY="$https_proxy" | ||
``` | ||
|
||
`NO_PROXY` is necessary to not suffer the performance or blocking should the port become unavailable |