Thought I’d start using Git from my workplace too. Why not! Little did I realize it would take away a lot of my time today & yesterday …
For starters we have a proxy at work. Git can work with proxies, including those that require authentication. Issue the following command:
|
1 |
git config --global http.proxy http://mydomain\\myusername:mypassword@myproxyserver:8080 |
Or add the following to your global config file:
|
1 2 |
[http] proxy = http://mydomain\\myusername:mypassword@myproxyserver:8080 |
Apparently this only works with Basic authentication but since version 1.7.10 it works with NTLM authentication too (I didn’t test this). That’s no dice for me though as there’s no way I am going to put my password in plain text anywhere! So I need a way around that.
Enter Cntlm. Cntlm sits between the proxy and your software. Its runs on your machine and authenticates with the proxy/ proxies you specify. (The config file takes password hashes instead of the plain text password). Your programs talk to Cntlm without any authentication; Cntlm then talks to your proxy after proper authentication etc. Cntlm is quite portable. When installing it creates a service and all, but you can run it by launching the exe file and pointing it to the config file. Very convenient. I quickly created a shortcut with this and pinned to my taskbar so I can launch Cntlm whenever required (and it stays in the foreground, so closing the window will close Cntlm).
This way I can pull repositories over https. When I tried pushing though, I was stuck. I am asked for a username/ password and while I am entering the correct details it keeps rejecting me:
|
1 2 3 4 |
Username for 'https://github.com': xxxx Password for 'https://xxxx@github.com': remote: Invalid username or password. fatal: Authentication failed for 'https://github.com/rakheshster/BatchFiles.git/' |
Turns out that’s because I use 2 factor authentication so I must create an access token. Did that and now I can push!
But that’s not very ideal as I don’t like storing the access token someplace. It’s a long piece of text and I’ll have to paste it in Notepad and copy paste into the command prompt each time I push.
Notice above that I am using HTTPS instead of SSH as is the norm. That’s because SSH won’t work through the proxy. If SSH works I could have used keys as usual. The good thing about keys is that I can passphrase protect it so there’s something known only to me that I can type each time. And if I ever need to revoke access to my office machine I only need revoke that key from GitHub.
SSH can’t be tunnelled through the HTTP proxy. Well not directly at least, through there is connect.c which is an SSH over HTTP proxy. Luckily it has Windows binaries too so we can try that.
But before that I want to see what I can do to ease access tokens an HTTPS access.
Turns out Git has ways to ease entering passwords or access tokens. Starting with version 1.7.9 it has the concept of credential helpers which can feed Git with your credentials. You can tell Git to use one of these credential helpers – maybe the GNOME Keyring – and Git will get your credentials from there. Older version of can use a .netrc file and you can do the same with Windows version of Git too. You can also cache the password in memory for a specified period of time via the cache credential helper.
Git 1.8.1 and above has in-built support for Windows (via the wincred helper). Prior versions can be setup with a similar helper downloaded from here. Both helpers store your credentials in the Windows Credential Store.
So it is not too much of a hassle using Git with HTTPS via an proxy like Cntlm and using the in-built credential helper to store your credentials in the Windows Credential Store. And if you ever want to revoke access (and are using two-factor authentication) you can simply revoke the access token. Neat!
Back to SSH. Here’s the Wiki page for connect.c, the SSH over HTTP proxy I mentioned above.
The Wiki page suggests a way to test SSH through connect.c. But first, here’s what the SSH link for one of my repositories look like:
git@github.com:rakheshster/BatchFilesgithub.com, the username is git, and the path I am trying to access is rakheshter/BatchFile (i.e. username\repository). Let’s see if I can connect to that via connect.c:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
C:\>connect.exe -H 127.0.0.1:53128 -d github.com 22 DEBUG: making direct addr list from network adapter address: DEBUG: adding direct addr entry: 192.168.50.0/255.255.255.0 DEBUG: adding direct addr entry: 127.0.0.0/255.0.0.0 DEBUG: 2 direct address entries. DEBUG: relay_method = HTTP (3) DEBUG: relay_host=127.0.0.1 DEBUG: relay_port=53128 DEBUG: relay_user=rakhesh DEBUG: local_type=stdio DEBUG: dest_host=github.com DEBUG: dest_port=22 DEBUG: checking github.com is for direct? DEBUG: github.com is for not direct. DEBUG: connecting to 127.0.0.1:53128 DEBUG: begin_http_relay() DEBUG: >>> "CONNECT github.com:22 HTTP/1.0\r\n" DEBUG: >>> "\r\n" DEBUG: <<< "HTTP/1.1 403 Forbidden\r\n" DEBUG: http proxy is not allowed. FATAL: failed to begin relaying via HTTP. |
The syntax is straight-forward. I launch connect.c, telling it to use the proxy at 127.0.0.1:53128 (where Cntlm is listening) and ask it to connect to github.com on port 22 (the SSH port). The -d switch tells connect.c to emit debugging info.
From the output I see it fails. Bummer! My work proxy is blocking traffic to port 22. Not surprising.
Thankfully GitHub allows traffic over port 443 (the HTTPS port). Must use hostname ssh.github.com though instead of github.com. Let’s test that:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
C:\>connect.exe -H 127.0.0.1:53128 -d ssh.github.com 443 DEBUG: making direct addr list from network adapter address: DEBUG: adding direct addr entry: 192.168.50.0/255.255.255.0 DEBUG: adding direct addr entry: 127.0.0.0/255.0.0.0 DEBUG: 2 direct address entries. DEBUG: relay_method = HTTP (3) DEBUG: relay_host=127.0.0.1 DEBUG: relay_port=53128 DEBUG: relay_user=rakhesh DEBUG: local_type=stdio DEBUG: dest_host=ssh.github.com DEBUG: dest_port=443 DEBUG: checking ssh.github.com is for direct? DEBUG: ssh.github.com is for not direct. DEBUG: connecting to 127.0.0.1:53128 DEBUG: begin_http_relay() DEBUG: >>> "CONNECT ssh.github.com:443 HTTP/1.0\r\n" DEBUG: >>> "\r\n" DEBUG: <<< "HTTP/1.1 200 Connection established\r\n" DEBUG: connected, start user session. DEBUG: <<< "Connection: close\r\n" DEBUG: <<< "\r\n" DEBUG: connected DEBUG: start relaying. |
Superb! It works.
Now all I need to do is open/ create %HOMEDRIVE%\.ssh\config and add the following lines:
|
1 2 3 4 5 6 7 |
Host * ProxyCommand "C:\path\to\connect\connect.exe" -H 127.0.0.1:53128 %h %p # force github.com:22 to go to ssh.github.com:443 as only HTTPS port is allowed by my proxy Host github.com Hostname ssh.github.com Port 443 |
All this does is that it tells SSH to launch connect.c to pass SSH connections through my proxy. Further, for any connections to github.com (on port 22), connect to ssh.github.com on port 443 instead.
Simple! Once I do these I can start pushing & pull Git over SSH too. Not bad eh.
While writing this post I discovered that connect.c is already a part of the Windows version of Git, so there’s no need to download it separately. Super!