From 5c6faad7eec00c02479e4a8dc46cb875f825f41e Mon Sep 17 00:00:00 2001
From: Jake Howard <git@theorangeone.net>
Date: Sat, 27 Jan 2018 15:58:44 +0000
Subject: [PATCH] Add 'Opening Port 22' post

---
 .spelling                        |  3 ++
 content/posts/opening-port-22.md | 58 ++++++++++++++++++++++++++++++++
 2 files changed, 61 insertions(+)
 create mode 100644 content/posts/opening-port-22.md

diff --git a/.spelling b/.spelling
index 05f138a..027eea2 100644
--- a/.spelling
+++ b/.spelling
@@ -71,3 +71,6 @@ KeePass
 nylas-mail-lives
 Alacritty
 scrollback
+eduroam
+RemoteApp
+subgraph
diff --git a/content/posts/opening-port-22.md b/content/posts/opening-port-22.md
new file mode 100644
index 0000000..1f72cfe
--- /dev/null
+++ b/content/posts/opening-port-22.md
@@ -0,0 +1,58 @@
+---
+title: Opening Port 22
+date: 2018-01-23
+subtitle: Using an SSH reverse tunnel to bypass a firewall 
+---
+
+My university has a development sever, which it uses to host our coursework without the need to setup a development environment locally. It also enables lecturers to mark our work in a controlled environment, without needing to spin up an environment, and run untrusted code on their machines, a security hole I'm more than likely to take advantage of! 
+
+For reasons unknown, only HTTP ports (80, 443) are available from machines other than those permanently on-site (even eduroam doesn't work!). Their solution to this problem is _RemoteApp_, which, like most windows products, doesn't work very well under Linux!
+
+With coursework requiring deployment onto this server now, access to SSH is essential (besides FTP, but who really wants to use that?). But, how to get SSH access to a server, without needing to use the terrible _RemoteApp_?
+
+## SSH Reverse Tunnels
+SSH has the ability to create a reverse tunnel between 2 machines, by using a 3rd as a gateway. Assuming the destination server has the ability to SSH out of its firewall, a separate SSH connection can use that connection as a tunnel to communicate.
+
+{{< mermaid caption="Network layout" >}}
+graph LR
+
+A[Client]
+B[Intermediary]
+
+subgraph Firewall
+C[Server]
+end
+
+A-->B
+C-->B
+{{< /mermaid >}}
+
+The intermediary server has to allow SSH connections from both the server and your client. The magic here happens because unless the server is in a highly controlled environment (where you shouldn't be doing this anyway), traffic is likely unrestricted outbound through the firewall.
+
+### Step 1: _Opening Port 22_
+Technically not opening a port, but it does sound cooler!
+
+Create the tunnel between the server and your intermediary server. Obviously, This must be done from the server, rather than from the intermediary:
+
+```bash
+ssh -R 12345:localhost:22 intermediary-user@intermediary
+```
+
+`intermediary-user@intermediary` should be replaced with your server credentials. 
+
+This will create a tunnel from the server to the intermediary, on port `12345`. This port is arbitrary, however does have to be unused. 
+
+### Step 2: The connection
+And now, to actually connect. From your local machine, simply run:
+
+```bash
+ssh -A intermediary-user@intermediary -W server-user@localhost:12345
+```
+
+After giving your credentials twice (once for the intermediary, then again for the final server), you should be met with a standard shell, on the destination server.
+
+#### Making connection easier
+SSH has many configuration options available to ease this process, such as using keys for authentication over passwords, and transparently connecting to the intermediary server when trying to connect to the server. These techniques are most commonly used when interfacing with an [SSH Bastion](https://tenmilesquare.com/using-ssh-through-a-bastion-host-transparently/).
+
+My personal tool of choice for managing config like this is [`assh`](https://github.com/moul/advanced-ssh-config).
+