#Should You Use HTTPS or SSH For Git? – CloudSavvy IT

When connecting to remote Git repositories like Github, you usually have two connection options—HTTPS or SSH. Both have their uses, and while SSH is generally considered more secure, the question is a little more complicated than that.

What’s The Difference?

The method of authentication you use to connect to a Git repo depends on the URL your remote is configured with. The default URL format Github uses is HTTPS, which communicates directly over the web protocol:

https://github.com/user/RepoName.git

However, you can also use SSH. While you’re not opening an interactive shell and executing commands, it’s still the same format as if you were connecting to a regular SSH-enabled Linux server:

user@ipaddress:folder/file

With Github and most services, you connect to the “git” user, and access the .git endpoint as a file under a folder with your username.

[email protected]:user/RepoName.git

Why Use HTTPS?

So, which one should you use? While SSH is usually considered more secure, for basic usage of Github, HTTPS authentication with a password is acceptable enough. In fact, Github themselves defaults to and recommends most people use HTTPS.

HTTPS has plenty of upsides:

• HTTPS is simpler. With how it works on Github, you just have to enter in your Github username and password, and you’ll be able to push and pull code. For the average user, this is perfectly fine.
• You don’t have to juggle multiple SSH keys around to use multiple devices.
• Port 443, which HTTPS uses, is open in basically any firewall that can access the internet. That isn’t always the case for SSH.
• The problem of password based auth can be minimized by using a Personal Access Token (PAT) on Github in conjuction with two-factor auth on your account.

The primary downside for most people is that you must enter your Git password every time you push. While it gets added to a cache, it’s not configured to cache permanently (though this can be changed). With SSH keys, it just uses the key file on disk every time.

Also, if you do use 2FA on your Github account, you are forced to either use SSH or a personal access token. Your default account password will not work.

Why Use SSH?

It’s a misconception that HTTPS as a protocol is significantly less secure than SSH. Both will provide you a secure connection safe from man-in-the-middle (MITM) attacks. Both protocols will do their job the same as long as the underlying keys are secured. Both will use public-key based authentication anyway, though HTTPS with Git will send your password over the wire. And both protocols can be configured to also use multi-factor authentication (MFA/2FA), although with Github it is easier to use MFA on your account if you use SSH keys.

Where SSH takes the lead is with the authentication factor—the key. The length of it alone makes it harder to accidentally leak, and due to it being unwieldy and unique, it’s generally more secure. The only downside is it’s stored as a user-accessible file on your hard drive rather than in your head, but given how bad humans are at security, it’s probably better that way.

Also, it’s not prone to getting caught up in a data breach. It’s guaranteed not to be reused, but it’s also never even stored on someone else’s server. Because you only give Github your public key, and use your private key on your end to perform the authentication challenge, there’s no risk of it being exposed, or even ever sent over the wire.

SSH has plenty of downsides, but they can be mitigated if you know what you’re doing:

RELATED: How to Use a Different Private SSH Key for Git Shell Commands

SSH can even be tunnelled over HTTPS when accessing Github, using the ssh.github.com hostname in your SSH config. While this may not be true for all Git services, it’s a nice plus for the big one:

Host github.com
  Hostname ssh.github.com
  Port 443

SSH keys can also be chained together using SSH agent forwarding, which allows you to connect to a remote server, and then use the SSH key on your client machine to authenticate. The remote server acts as the middle man, unaware of your SSH key.

RELATED: What is SSH Agent Forwarding and How Do You Use It?

What Should You Use?

The question is, should you bother with it? If you’re experienced with a command line, it’s not too hard to just use keys, and most people will anyway simply because it’s easier to configure once and never enter a password again. It also works better with 2FA, which most high-security Github accounts should likely be using.

If you’re just looking for an easy experience, HTTPS is secure as long as your password is secure. There’s a reason Github has it default and even recommends it—it works well and is easy to understand.