mike#.Net Development

PuTTY is a great tool for network connectivity when using Tunnels. This article will show you how to create a Forward Tunnel to allow access to remote resources that would otherwise be blocked by a firewall.

In this scenerio you have a computer at work and you wish to access a remote Git server which operates via SSH on the standard port 22. However, outbound connections to port 22 are blocked by a firewall – only ports 80 (http) and 443 (https) are open. In addition the firewall operates as a HTTP proxy requiring authentication.

The first step is to establish a remote SSH server on ports 80/443. I prefeer 443 simply because it implies SSL encryption, and SSL is encrypted traffic. Adding port 443 to an OpenSSH server is very easy, simply add the line:

Port=443

to the /etc/ssh/sshd_config file, right below the existing “Port 22” line.

Restart the SSHD:

service ssh restart

You can now configure PuTTY to connect to the remote host via port 443.

It’s also easy to configure PuTTY to perform this connection through the proxy. Not all networking tools have the ability to use a proxy, which is one reason I use this technique.

Open your PuTTY connection and you should have no problems now reaching your remote SSH server on 443.

Next we will set up the Forward Tunnel. The Forward Tunnel will allow a local application to connect to a remote server through PuTTY. For example, I will use Git to connect to localhost on a port that PuTTY will be listening on, PuTTY will automatically forward that connection through the SSH tunnel to the remote SSH server, which will in turn forward the connection to whereever I specify.

Configure as follows. Source port is the local port PuTTY will listen on. Destination is where the connection will be forwarded to when it comes out the other end of the tunnel on the server side. In this example, the destination will be a Git server on port 443.

Note the Git server does not have to be on port 443. I can be on port 22, or any port at all. You could for example forward to http://www.google.com:80, an all local http connections on your local port 22 will reach google on port 80.

Click add and you will see the following:

This illustrates the 4L22 clearly means it’s IPv4, Local tunnel, on port 22, and shows the destination name and port.

That’s it. To use git, simply open up git bash and issue the following:

git clone git@localhost:[Repository Name]

To push changes back to the server, you first need to establish the tunnel with PuTTY, then issue:

git push master origin

Git sees the repository as being hosted locally on port 22, none the wiser that it’s call is being forwarded through PuTTY -> HTTP Proxy -> Port 443 -> Remote SSHD -> git.yourcompany.com:443

See my previous post AWS Git Repository with Alestic Gitolite for creating an AWS Git Repository

I place my Git repositories on a seperate EC2 Volume for three reasons:

1. Make backup of the repositories easier vs backing up the entire Git server vai EBS Snapshots.
2. Make migrating the repositories to a new EC2 instance easier.
3. Make increasing the size of the repository volume easier.

Create the EBS volume. Be sure to select the same Zone as where you created your Git instance. The volume size should be larger then the amount of your repository data with acceptable growth space. After creation, edit the Name tag and call it “Git Repositories”.

Attach the volume to your Git instance. If you already have additional volumes attached you will need to change the default Device:

/dev/sdf

Simply make it /dev/sdg. The Alestic Git Server Ubuntu instance I’m using will automatically map that device to another device name, I’ll show you have to discover that name shortly. It may take a few minutes for the volume to attach to the instance.

Here’s a good Ubuntu post on InstallingANewHardDrive

SSH into your server. Follow the above documentation, or what I’ve written below.

To discover the device name:

sudo fdisk -l

Disk /dev/xvda1: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders, total 16777216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/xvda1 doesn't contain a valid partition table

Disk /dev/xvdf: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/xvdf doesn't contain a valid partition table

By default you should see your system volume /dev/svda1. You should also see a second volume /dev/xvdf (ifyou have more than one volume attached, it will be named differently – make note and replace appropriately in the following commands)

Create a new partition using fdisk:

sudo fdisk /dev/xvdf

Create a new (n) primary (p) number (1) default first sector / default last sector finally write

The new partition will be named /dev/xvdf1 . Note the 1 to indicate the first partition.

Format the partition:

sudo mkfs -t ext4 /dev/xvdf1

Create a temporary mount point and allow write:

cd /mnt/
sudo mkdir repositories
sudo chmod 777 repositories

Mount the new volume

sudo mount /dev/xvdf1 /mnt/repositories

Disable access to Git.

Switch user to git and copy existing repositories into new volume and exit back to ubuntu user deleting the temporary mount point.

sudo su git
cd repositories
cp -R /home/git/repositories/* .
exit
sudo umount /dev/xvdf1
sudo rm -R repositories

You can at this point delete the old repositories in the /home/git/repositories folder, but I’ll leave that as an exercise for the user. Next we will mount the new volume in /home/git/repositories.

Edit fstab:

sudo nano /etc/fstab

Add the following line:
/dev/xvdf1 /home/git/repositories ext4 defaults 0 2

Mount the volume

sudo mount -a

Change ownership of the volume to user git:

sudo chown git:git /home/git/repositories

At this point reboot the server and verify. Reenable access to Git.

I will be using the Alestic Gitolite AIM ami-b0d309d9. This is not the Marketplace AWS located here, it looks like the Market place version does not qualify for the free tier.

The Alestic Git Server aim was taken directly from the documentation. Using the ami directly when creating the instance allows for the free tier pricing.

ec2-run-instances --key $USER  --instance-type t1.micro ami-b0d309d9

Create a new Instance, use the Community AMI ami-b0d309d9. When searching for ami-b0d309d9 the Marketplace version will show up also, select ami-b0d309d9 directly. Note, when a new version is released the ami number will change, check the documentation link above for the new ami number.

I always select a particular zone, the reason is because volumes are not available across zones and I like to keep all my data in one area.

Alestic recommends uploading your own ssh pub key for use when creating the instance, and this is a good pratice and this does make accessing your instances easier if you are running a Linux workstation. However I’m running Windows, so I create a new key for each instance and store them locally on my NAS. I use PuTTY and simply reference the individual key for each insance.

I also find it a good pratice to create a security group for each individual instance. The reason is you can not change the security group for an instance, only change the open ports. If I have two instances using the same security group and I need to open a port for one instance it will be opened for both instances if they share the same group. Therefore, don’t use the default group, create a new one, or reuse an existing one specific for your Git server.

After creating the instance, I always verify the Name tags for both the instance itself and the volume, naming the volume something such as “Git System”.

Create an Elastic IP and associate it with your instance. Create a DNS entry from your provider for this ip for easy access such as “git.mycompany.com”.

Log into your new Git server and lets begin configuration. When you SSH to the server you must specify the key used when creating the instance. The login username will be ‘ubuntu’ as is true for all Canonical Ubuntu AWS instances.

I like to use the ubuntu account to initially configure the gitolite-admin repository. However, if you try to clone the repository you will receive an error. The problem is the ubuntu user does not have id_rsa/id_rsa.pub files in .ssh.

Upload the ssh key used when creating the instance to /home/ubuntu/.ssh/id_rsa . I use puttygen to extract the public key from the private key, then upload this file to /home/ubuntu/.ssh/id_rsa.pub. I use WinSCP to perform the upload. Once uploaded, you will need to update the key permissions:

chmod 600 id_rsa
chmod 644 id_rsa.pub

Gitolite was initialized to allow access only from the key used to create this instance. The ubuntu account will now use this key and you can clone the gitolite-admin repository. I usually create a Git folder under the ubuntu home directory:

mkdir Git
cd Git
git clone git@[your server name, dns, ip, or localhost]:gitolite-admin

Now we can add a user. This is as easy as simply placing the users public key in the gitolite-admin/keydir folder. You will see already in this folder is the public key of the key used to create this instance. The same private/public rsa keys we placed in the ubuntu .ssh folder earlier, granting us access to the repository.

Adding a repository is also quite easy. Simply edit the gitolite-admin/conf/gitolite.conf file. Here’s my default values:

repo gitolite-admin
    RW+     =   Git
    RW+     =   mike

repo testing
    RW+     =   @all

repo Project1
    RW+     =   mike

I’ve added mike.pub to the keydir and can now grant that key RW+ access to the gitolite-admin repository. I’ve also added a new repository called Project1 and granted mike RW+.

Push the changes to the git server to make them take effect, from the gitolite-admin folder:

git add .
git commit -m "initial configuration"
git push origin master

See my next post Creating AWS Git Repository Volume to create a seperate volume to hold your Git repositories.