When it comes to secure communication, there are a few options you have at your disposal. HTTPS, or Hypertext Transfer Protocol Secure, is a protocol that encrypts data between the client and server. SSH, or Secure Shell, is a protocol used for secure remote access. Both HTTPS and SSH offer benefits and drawbacks. For example, HTTPS is more secure than SSH because it encrypts the data in transit. However, HTTPS can be more difficult to set up and maintain because it requires a secure connection between the client and server. Ultimately, which protocol you choose depends on your specific needs. If you need to keep your data confidential but don’t want to spend extra time setting up security measures, then HTTPS may be the best option for you. On the other hand, if you need to access files remotely frequently and don’t mind sacrificing some security measures, then SSH may be a better choice. ..
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:
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:
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.
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.
However, it isn’t as simple as it used to be—as of August 2021, Github disabled using your account password to authenticate. You will need to create a Personal Access Token, which acts like a second password, but is unique and can be given specific permissions. It also allows you to use 2FA on your account with no issues.
HTTPS has plenty of upsides:
HTTPS is simpler. For most services besides Github, you just have to enter in your username and password, and you’ll be able to push and pull code. 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 primary downside for most people is that you must enter your Git password/token 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.
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:
Setting up your Github account to use your SSH key only requires a few commands and clicks in their settings. Managing multiple keys per computer isn’t trivial, but it’s not too hard to set up by configuring your SSH host file and Git remotes. Transfering keys to other machines is possible, but since you can have multiple SSH keys, this isn’t necessary.
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:
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.
