Today we’ll cover how to connect to github and EC2 through a draconian proxy allowing only port 80 and 443. Github uses SSH, so like EC2 it can be connected to using SSH tunnelling. This article is based on a blog post by tachang[1], which needed some additional explanation and changes to work behind my proxy. I will be explaining how to connect on a unix-based machine, but these settings should also work on windows (see tachang’s article for windows setup[1]).
Getting ready
You will need to install corkscrew[2] on your machine for tunneling SSH through the proxy, and git (if you don’t have it already).
You will also need superuser access on your own machine and any EC2 instance that you want to connect to.
How do it…
Once corkscrew is installed, simply edit or create ~/.ssh/config with the following:
ProxyCommand /usr/local/bin/corkscrew proxy.<yourCompany>.com 8080 %h %p
Host github.com
User git
Port 443
Hostname ssh.github.com
IdentityFile "/Users/msnider/.ssh/rsa_id"
IdentitiesOnly yes
TCPKeepAlive yes
Host <ec2PublicDNSForYourServer>
Port 443
User ubuntu
IdentityFile "/Users/msnider/.ssh/rsa_id"
IdentitiesOnly yes
TCPKeepAlive yes
Changes to ~/.ssh/config happen immediately, so at this point we can check to see if github connectivity has been restored:
>ssh github.com Hi mattsnider! You've successfully authenticated, but GitHub does not provide shell access. Connection to ssh.github.com closed.
When outside of the proxy, SSH to your EC2 instance and update the sshd_config file (mine was located at /etc/ssh/sshd_config on ubuntu) to also listen on port 443:
# Package generated configuration file # See the sshd_config(5) manpage for details # What ports, IPs and protocols we listen for Port 22 Port 443 ...
Then restart the server so that the changes take effect. Also, log into EC2 and update the DMZ of the server to allow connections on port 443. Then check to see if SSH connectivity to your server has been restored:
>ssh [email protected]<ec2PublicDNSForYourServer>
If you are not behind the proxy you can force SSH to use port 443 for testing:
>ssh -p 443 [email protected]<ec2PublicDNSForYourServer>
How it works…
Looking at the ~/.ssh/config, the ProxyCommand tells SSH to tunnel through a proxy when connecting to any host. Change the location of corkscrew to where yours is installed, replace the proxy server domain (don’t put http:// in front of the name) with yours, and change the proxy port 8080 to the one you connect to your proxy on. The %h and %p are special variables that will be populated by SSH dynamically (target host and port respectively).
Next the file defines all the hosts to connect to. We want to be able to connect to github.com and the EC2 public DNS for the instance. Under each Host definition the Hostname, Port, User, IdentityFile are important. The Hostname is the server DNS to connect to, if the Hostname is different from the Host; notice that the one under github.com has been changed to ssh.github.com (the github server that allows port 443). The Port is the port to connect on, and since your proxy blocks everything but 80 and 443, you need to use one of those two. The User should be changed to the user used to SSH into the server. And IdentityFile is the location of your private identify file used for SSHing to the server. I used RSA keygen[3] and have the same key on my server and github, but you can use any number of identify files and other cipher formats supported by SSH.
Lastly, for SSHing to your EC2 server, you need to modify the sshd_config file on the server. This file configures the SSH service on the server, and needs to be told to also listen to port 443. The SSH service can listen to as many ports as you want, so simply add the port 443 line under the port 22 line. I tried to just restart the SSH service, but Ubuntu wouldn’t let me, since I was logged in over SSH, so I ended up restarting the machine. Since, you cannot connect to this server when you are behind the proxy, you will need make this change outside the office. Also, port 443 is typically reserved for secure HTTP connections, so adding this port may conflict with an existing HTTP service. The best way to get around this is to have a second server (without HTTP services running) that you SSH into when at work and connect through that machine to port 22 on the machine running the webserver.