Git network operations in Visual Studio 2013

Visual Studio 2013 includes in-the-box support for Git version control. That support includes the ability to perform Git network operations from inside of Visual Studio, such as cloning a repository, or performing a fetch, push, or pull operation on an existing repository.

An endpoint for a clone, fetch, push, or pull operation in Git is called a “remote.” Visual Studio 2013’s Git support contains support for remotes using the following protocols.

• HTTP (i.e. https://github.com/libgit2/TestGitRepository, or https://yourname.visualstudio.com/DefaultCollection/_git/YourRepo)
• File paths (i.e. F:\myrepo.git, or \\servername\sharename\myrepo.git)
• git:// URIs

As of this writing, Visual Studio 2013 does not have support for ssh-based remotes. If you have a Git remote that uses SSH and you try to perform a network operation in Visual Studio, you’ll get the message “This transport isn’t implemented. Sorry.” (This message comes from the libgit2 library.) I don’t have a timeline for when support for SSH remotes might be implemented in Visual Studio.

HTTP endpoints

When performing network traffic against an HTTP endpoint, Visual Studio uses the System.Net stack (HttpWebRequest and friends) to actually issue the web requests. Both HTTP and HTTPS URIs are supported.

The System.Net stack in the .NET framework has full support for web proxy configuration through the Internet Options page. If you need to use a web proxy to communicate with your remote endpoint, you should set up your proxy configuration there. Start the Control Panel, then select Internet Options to open the Internet Properties dialog. On the Connections tab, at the bottom of the page is a button labeled “LAN settings.” Clicking this button opens the proxy configuration dialog for Internet Explorer.

The System.Net stack also includes support for proxy authentication (HTTP status code 407), if your environment requires it.

Special considerations for HTTPS endpoints

If an HTTPS URI is used for a remote, the Windows certificate store is used to validate the server’s SSL certificate.

If the server to which you are pushing/pulling has a self-signed certificate, then as of this writing, we give an unfortunate and vague error message to the user. “An error occurred while sending the request” is what is commonly seen. You should use the Windows certificate manager (certmgr.msc) to add the self-signed certificate (or the authority at the top of the certificate’s chain) to the Windows certificate store as a trusted certificate, and then try your network operation again. We hope to improve on this user experience in a future release, because it is very hard to make the mental jump here from “an error occurred” to “oh, I need to add the certificate to my certificate store.”

Visual Studio 2013 also supports the use of client certificates as part of the SSL negotiation, if the server requires it. Certificate selection is automatic, by default. If you need to use a specific client certificate to prove your identity to the server, you can use the command-line “tf certificates” command to select which client certificates are eligible for presentation.

Authentication

When using HTTP to communicate with a remote, Visual Studio may be required to authenticate with the remote server. Visual Studio 2013 supports 3 methods of authentication when communicating with a Git server over HTTP.

• Basic authentication
• Integrated Windows authentication
• Team Foundation Service federated authentication (used only when communicating with endpoints at https://*.visualstudio.com/)   

Each authentication method has its own credentials acquisition dialog.

Basic authentication

If you are communicating with a third-party Git hosting service like Github or Bitbucket, you will probably be using Basic authentication to send your password in cleartext inside the SSL tunnel. Visual Studio 2013 is able to store and retrieve basic auth credentials from the Windows credentials vault using the same protocol as the Windows Credential Store for Git. If you have this plug-in for Git for Windows installed, then once you save your credentials once, you should be able to use both git.exe and Visual Studio to perform network operations without any password prompts.

If you ever want to clear the password from storage, you can use the Credential Manager in the Control Panel to remove it, or use cmdkey.exe from the command line.

Windows authentication

If you are using an on-premises Team Foundation Server 2013 server to host your Git repository, then you probably authenticate to it with integrated Windows authentication. If you are logged on with your domain account, authentication from Visual Studio should be transparent.

However, git.exe (which uses CURL for its transport layer) will not be able to retrieve your credentials transparently. You can either type your DOMAIN\username and password strings when you push/pull, or you can install the Windows Credential Store for Git and persist your credentials for git.exe’s use.

Most customers do not use HTTPS to secure their Team Foundation Server 2013 server on their intranet. However, if your organization does use HTTPS, and has its own certificate infrastructure used to sign the certificate for the Team Foundation Server 2013 deployment, then you may find git.exe fails to validate the SSL certificate. This is because the root certificate for your organization’s certificate infrastructure is pushed to your machine’s Windows certificate store through Active Directory, but git.exe cannot see it. Git for Windows uses OpenSSL for its certificate store and the set of certificates comes with the Git for Windows package. You can disable SSL verification for git.exe through your .gitconfig file, or use the http.sslCAInfo and http.sslCAPath configuration options to help Git for Windows find the certificate at the root of the certification chain for your TFS 2013 deployment.

Federated authentication

This authentication mechanism is used only by the Team Foundation Service (https://*.visualstudio.com/) and is based on Windows Live ID. If you have already logged into your Team Foundation Service account using the Team Explorer, you should find that authentication for push, pull, clone, and fetch operations is transparent.

The command-line Git for Windows executable, git.exe, does not support this authentication method. If you want to perform network operations against a Team Foundation Service-based Git repository using git.exe, you will need to provision a basic authentication username and password using the Edit Profile dialog in the Team Foundation Service web interface. You can then use that basic auth username and password from the command line. (Visual Studio will still prefer to authenticate using federated authentication.)

Comments

• Anonymous
  October 21, 2013
  If only I had seen this about 30 minutes ago, I would have saved some time =), thanks for the post

• Anonymous
  December 27, 2013
  The comment has been removed

• Anonymous
  December 27, 2013
  Thanks Paul. I see at least two big hurdles in front of us if we want to ship SSH support in Visual Studio.

1. The current SSH support in libgit2 is built on top of openssl (indirectly, through libssl2), but we would need to rig it up to run through the Windows cryptography stack instead.
2. Licensing - we would need to do a deep investigation of the libssl2 library and ensure that its license is compatible with Visual Studio's, and that all the code has proper provenance. For your particular case, you can still use Visual Studio to work with your Git repository -- but you will have to use another tool (like git.exe) to do fetch, push, pull, and clone operations. Thanks

• Anonymous
  September 30, 2014
  Any progress and/or likely ETD for GIT SSH support in Visual Studio?

• Anonymous
  April 15, 2015
  April 2015 and still no SSH support?

• Anonymous
  May 29, 2015
  I would like to inquire if anyone, using the Git format, through the TFS 2013 ALM (project.visualstudio.com) has experienced a greater network demand and slowdown when implementing it this way.

• Anonymous
  June 15, 2015
  June 2015 and still no ssh support?

• Anonymous
  July 08, 2015
  It appears that in order for this to work with an authenticating proxy, Visual Studio needs to already have your proxy credentials; the Git client will not prompt you for them.  One way to do this is to use the Enter Credentials button under Product Videos on the Start Page.

• Anonymous
  July 29, 2015
  When will we see Git SSH support in Visual Studio?  Is there an open issue tracking this work we can vote on or follow somewhere?

• Anonymous
  August 27, 2015
  A number of commenters have asked about SSH support for Git in Visual Studio, Team Foundation Server, and Visual Studio Online. I would encourage those of you who are enthusiastic about adding this feature to vote for the feature on UserVoice. Here is the link: visualstudio.uservoice.com/.../3801342-add-support-for-ssh-keys-as-alternate-authenticati