project: ssh tunnel that doesn't suck (codename meatviewer)

diff --git a/meatviewer/client.sh b/meatviewer/client.sh
index 4745489e27c156dcd1fa03dd54062a539610a274..fde5b76661de89e958042df8d30f567501d34d34 100644 (file)
--- a/meatviewer/client.sh
+++ b/meatviewer/client.sh
@@ -7,7 +7,7 @@ function print_usage {
        script that sets up a reverse ssh tunnel, and optionally starts a VNC server as well if the START_VNC environment variable is not null
        PORT is the port that your techy needs access to. In general, for graphical issues use 5900 and for command-line issues use 22
        REMOTE_PORT is the port that you'll get on the proxy server, any number over 1000 works as long as you and your techy plug in the same number
        script that sets up a reverse ssh tunnel, and optionally starts a VNC server as well if the START_VNC environment variable is not null
        PORT is the port that your techy needs access to. In general, for graphical issues use 5900 and for command-line issues use 22
        REMOTE_PORT is the port that you'll get on the proxy server, any number over 1000 works as long as you and your techy plug in the same number

-       user@proxy is just your username at the remote proxy machine
+       USER is just your username at the remote proxy machine, if left blank it is assumed to be the same as your username on your local machine

 "
 }
 
 "
 }
 


@@ -15,15 +15,6 @@ function print_usage {
 
 PORT_TO_FORWARD=$1
 REMOTE_PORT=$2
 
 PORT_TO_FORWARD=$1
 REMOTE_PORT=$2

-PROXY=$3
+USER=${3:-$(whoami)}

 
 

-ssh -T -R $REMOTE_PORT:localhost:$PORT_TO_FORWARD $PROXY
-
-# quick code that starts up a VNC server for us, if we like
-# this won't run if START_VNC is set
-[ -n $START_VNC ] || exit
-DISPLAY="${DISPLAY:-:0}"
-# -forever - x11vnc won't exit after the first disconnect
-# -shared - allow multiple clients to share the same screen
-# -localhost - only allow connections that are tunneled through localhost
-x11vnc -forever -shared -localhost
+ssh -T -R $REMOTE_PORT:localhost:$PORT_TO_FORWARD $USER

diff --git a/meatviewer/proposal.txt b/meatviewer/proposal.txt
new file mode 100644 (file)
index 0000000..b1ec408
--- /dev/null
+++ b/meatviewer/proposal.txt
@@ -0,0 +1,4 @@
+proposal for what we need for the techsupport server:
+*) a server with a public ipv4 address and SSH access
+*) sshd needs PortForwarding yes
+*) IDEA: a webserver that returns the ssh public key fingerprint of the techy's ssh key

diff --git a/meatviewer/what-is.mdwn b/meatviewer/what-is.mdwn
new file mode 100644 (file)
index 0000000..21c0056
--- /dev/null
+++ b/meatviewer/what-is.mdwn
@@ -0,0 +1,45 @@
+Sometimes people need tech support. Oftentimes, those people are behind firewalls and/or NATs. Oftentimes the tech support person is also behind a NAT.
+
+This presents us with a problem - we can't just connect to the user's public IP if they're behind a NAT, and we don't want to rely on them being able to port-forward.
+
+So, how do we access their computer?
+
+I'll explain how we can use nothing but SSH and a host on the public internet to implement a secure tunnel between two computers over WAN, allowing our techy to remote into our end user's computer.
+
+Firstly, NAT - NAT is a magical little tool that hides your private little home network from the rest of the internet\*. It allows TCP/IP connections to be initiated from the private side to the public side, but not the other way around\*.
+
+\* this is a lie
+
+Secondly, SSH - SSH is a wonderful little protocol that can be used for about anything. Most people use it to get a shell on a remote machine, but really just about any data can be sent through SSH.
+
+A neat little feature of SSH is ssh tunneling, actived by the -L switch. ssh tunneling takes all traffic directed at a given port, and spits it out the other end of the tunnel on the server - you specify a port on your local computer that you would like to forward to the server\*\*, it Just Works(tm). Note that this tunnel is unidirectional, you need something listening at the other end of the tunnel if you want to actually do anything.
+
+\*\* the ssh server does need to have `PortForwarding yes`, which fencepost currently has disabled (2020-09-03)
+
+If we try to have both our techy and our end user use regular ssh tunneling, nothing will happen because they're both throwing packets through the tunnel but nobody is actually catching them. You'll see errors like "error: channel 3: connect failed" if this is happening.
+
+There's also a neat little feature called reverse ssh tunneling, activated with -R; in a reverse tunnel, we take packets from the server and sends them to our local computer. reverse tunneling forwards packets from a port on the server to our local computer.
+
+Our theory of operation becomes apparent: forward traffic from our techy's computer to the proxy server, and then reverse-forward\*\*\* the traffic from our end user. Traffic goes into the port on our techy's computer, gets forwarded to our proxy, and then gets sucked back down the reverse tunnel created by our end user.
+
+\*\*\*"backward?"
+
+---
+
+![basically, how it works](packetflow.jpg)
+
+forgive my awful drawing skills
+
+---
+
+So, the commands we need to run are:
+
+techy: `ssh -L 2222:localhost:43130 user@proxyhost`
+
+end user: `ssh -R 43130:localhost:22 user@proxyhost`
+
+This sends traffic from `techy port 2222` through proxyhost and back down to `end user port 22`, where the end user hopefully has `sshd` running. The techy can then point their ssh client at localhost:2222 to log in to the end user's computer.
+
+43130 is just a random port number I chose, you can choose any port number you like above port 1000, just make sure it's the same port in both commands.
+
+You can have the user open up any port on their machine too, not just port 22. Change the command to `-R 43130:localhost:5900`, for example, to access a VNC server they have running. I just suggest using SSH where possible to save on bandwidth; using VNC over a WAN is less than pleasant.