SSH over SSL with BitBucket & GitHub.

I’ve recently decided to switch to using SSH (Secure Shell) access for all of my repositories on both BitBucket & GitHub.  I was previously using HTTPS access, however this frequently means that you end up with hard-coded usernames and passwords inside your Mercurial and Git configuration files.  Not the most secure approach.

I switched over to using SSH Keys for access to both BitBucket and GitHub and I immediately ran into a problem.  SSH access is, by default, done over Port 22 however this is not always available for use.  In a corporate environment, or over public Wi-Fi, this port is frequently blocked.  Fortunately, both GitHub and BitBucket both allow using SSH over the port that is used for SSL (HTTPS) traffic instead as this is almost always never blocked (Both Port 80 (HTTP) and 443 (HTTPS) are required for web browsing).

Setting this up is usually easy enough, but there can be a few slightly confusing parts to ensuring your SSH Keys are entered in the correct format and making sure you’re using the correct URI to access your repositories.  I found BitBucket that little bit easier to configure, and initially struggled with GitHub.  I believe this is primarily because GitHub is more geared towards Unix and OpenSSH users rather than Windows and PuTTY users.

Setting Up The Keys

The first step is to ensure that the SSH Key is in the correct format to be added to either your GitHub or BitBucket account.  If you’re using PuTTYGen to generate your SSH keys, the easiest way it to simply copy & paste the key from the PuTTYGen window:


In my own experience, I’ve found that BitBucket is slightly more forgiving of the exact format of the SSH Key.  I’d previously opened my private SSH Key files (.ppk file extension) in Notepad and copied and pasted from there.  When viewed this way, the SSH Key is rendered in an entirely different format as shown below:


It seems that BitBucket will accept copying and pasting the “public” section from this file (identified as the section between the lines “Public-Lines: 6” and “Private-Lines: 14”) however GitHub won’t.  Copying and pasting from the PuTTYGen window, though, will consistently work with both BitBucket & GitHub.

Configuring Client Access

The next step is to configure your client to correctly access your BitBucket and GitHub repositories using SSH over the HTTPS/SSL port.  Personally, I’ve been using TortoiseHG for some time now for my Mercurial repositories, but recently I’ve decided to switch to Atlassian’s Sourcetree as it allows me to work with both Mercurial & Git repositories from the same UI.  (I’m fairly comfortable with Mercurial from the command line, too, but never really got around to learning Git from the command line.  Maybe I’ll come back to it one day!)

normalsshBitBucket has a very helpful page on their documentation that details the URI that you’ll need to use in order to correctly use SSH over Port 443.  It’s a bit different from the standard SSH URI that you get from the BitBucket repositories “home page”.


Note the domain rather than the standard one!  You’ll also need to add the port to the end of the domain as shown in the image.

Configuring the client access for GitHub was a little bit trickier.  Like BitBucket, GitHub has a page in their documentation relating to using SSH over SSL, however, this assumes you’re using the ssh command line tool, something that’s there by default in Unix/Linux but not there on Windows (although a 3rd party implementation of OpenSSH does exist).  The GitHub help page suggests to change your SSH configuration to “point” your host name to run over Port 443.  That’s easy if you’re using the command line OpenSSH client, but if you’re using something like Tortoise or in my case, SourceTree, that’s not so easy.

ghnormalsshThe way to achieve this is to forget about fiddling with configuration files, and just ensure that you use the correct URI, correctly formed in order to establish a connection to GitHub with SSH over SSL.  The standard SSH URL provided by GitHub on any of your GitHub repository homepages (as shown in the image) suggests that the URL should follow this kind of format:

That’s fine for “normal” SSH access where SSH connects over the standard, default port of 22.  You’ll need to change that URL if you want to use SSH over the SSL port (Port 443).  The first thing to notice is that the colon within the URL above separates the domain from the username.  Ordinarily, colons in URLs separate the domain from the port number to be used, however here we’re going to add the port number separated by a colon from the domain and move the username part to be separated after the port number by a slash.  We also need to change the actual domain from to


Therefore our SSH over SSL URL becomes:

instead of:

(Obviously, replace the part of the URL with the relevant repository name!)

It’s a simple enough change, but one that’s not entirely obvious at first.

Website Security Presentation

At my place of work, we have “Thursday Tech Talks” that take place every Thursday afternoon over lunch.  The talks vary in subject matter, ranging from specific technologies through to more general subjects that are relevant to software development and IT in general.  Sandwiches and Muffins are kindly provided by the company so the talks are very well attended - who doesn’t want free sandwiches and muffins? Smile


The talks are given by members of staff, and each staff member can offer to talk about a subject that interests them on a company-wide Trello board that we have for just this purpose.  The Trello entries are then voted upon by other staff members, and every week, the person with the highest votes gets to give a presentation to other members of the company who wish to attend.


Well, this past week, it was my turn.  I’d opted to give a talk on Website Security and general security concepts and goals.  We had quite a large turn out for what was my very first time presenting (No pressure then!), and it was both flattering and petrifying giving my inaugural presentation to such a large audience, but it was also very exciting to do.


As mentioned at the talk, I’m making my slides and notes available for all to view and download.  I’ve used Google Docs Presentations (surprisingly good these days!) for the slides and notes, so they’re viewable online by visiting the following link:


Website Security Presentation – Slides & Notes


The entire presentation can be downloaded in a variety of formats (PDF, PPTX (Microsoft PowerPoint) etc.) by going to the

File > Download As menu.