HTTPS vs SSH in git


👤 Diwas Poudel    🕒 19 Nov 2022    📁 TECH

HTTPS vs SSH in git in 5 minutes

What is the difference between HTTPS and SSH in git? This is the question that every newbie has when they first start using git and GitHub. In this article, I will go over the concepts and practical applications of those protocols in git.

General Scenario:
For transferring data from client to server, protocols such as HTTP, HTTPS, ssh, FTP, sFTP, FTPs, and others are used. In standard HTTP, all information sent from client to server and vice versa is sent in plain text. Anything sent from the client and received by the server via a public network (the internet) in plain text format. As a result, those data are vulnerable, and hackers can act as a man in the middle, intercepting all requests and responses.

It can be no problem if you just use it for browsing a regular website since there does not involve any secure data. But if you want to transfer secure and sensitive data then we have to encrypt it. So even if hackers intercept those encrypted data then that makes no sense to him since it is in encrypted form.

As a result, many secure protocols such as HTTPS, ftps, sftp, ssh, and SSL/TLS were created.

Don't Miss: CPU Hyperthreading in depth

From Git Perspective:

In a git, there may be private and public repositories. For public repositories, even data send from server to client and vice versa with HTTP does not have much impact. However, if you have private repositories and many developers are working on them, it is necessary to transfer data securely between client (developer) computers (ie. Git Client) and git private repositories so that no hacker can intercept those data.

Git uses several protocols for client-server communication :

  • HTTP
  • HTTPS
  • SSH
  • Plain git.

However, ssh and HTTPS are secure protocols. As a result, many git servers, such as Github, Bitbuckets, and GitLab, use those two popular cryptographic network protocols.

So, there are two popular cryptographic network protocols to use when cloning, pushing and pulling changes between GitHub repositories and your computer. 1) HTTPS and 2) SSH

Common in both HTTPS and SSH

  • Both HTTPS and SSH are communication protocols.
  • Both HTTPS and SSH work for providing a reliable and secure connection
Don't Miss: Microsoft Technology Stack

HTTPS:

HTTPS is a secure version of HTTP that encrypts data transmitted between the client and the server. When hackers intercept encrypted data, they are unable to make sense of it and cannot reverse it. To establish a connection, HTTPS used port 443. It uses the Public/Private Pair authentication mode.

It is mainly developed for secure transferring of data between client and server.

SSH:

SSH means "Secured Shell".It is also a secured version, where data sent between the client and server is encrypted.SSH used port 22 is used to negotiate or authenticate the connection. The remote device authentication is done by public-key cryptography. Its mode of authentication is public/private Pair, or userid/password pair.

It is made to reduce security threats for remote server login.

How does SSH work?

SSH can be configured with a pair of keys called private and public keys. These keys are generated mathematically using various algorithms such as the RSA Algorithm, and EdDSA algorithm. Now let's look at how it works. Private and public keys are generated on the client and sent to the SSH server. The client now has both your public and private keys, while the server only has your public key.

When a client wants to connect to a server (in our case, Git Server), the server simply encrypts the random number using your public key and sends the encrypted message back to the client, who then decrypts the encrypted message using his private key and sends the decrypted information to the server. Then server verifies that the client's decrypted information is correct. If the information is correct, then authentication successfully happens.

ssh-public-private-keyNote one thing the SSH Private key should be securely stored by the client and if compromised then unauthorized users can get access to the git server.

In a nutshell and in layman's terms, we have private and public keys generated in SSH, and then public keys are stored on Git hosting. Now onward if we want to do any action in git, the private key stored on the PC is matched with the public key stored in git hosting. If they match, then without prompting the username and the password you are allowed to do this action.

Git with HTTPS and SSH:

Here, I will discuss with git hosting service provider Github. But will work the same for Gitlab or Bitbucket as well.

Git with HTTPS

Starting git with HTTPS for cloning, pulling, and pushing is much easier and can be done with much less setup.

If you use HTTPS URLs on the command line to get a remote repository, git fetch, git pull, or git push, git will ask for a username and password.
 
If the links show origin https . .. then you are using an HTTPS link.
 

git clone with https in action

fig. git clone link in action 

Git with HTTPS uses password-based authentication for doing every action like git push, git clone, git fetch, and git pull, etc. So, it is recommended to create a strong and unique password by using a password manager.

Generally, It is found that most of the users coming from a Windows Background use HTTPS instead of SSH.

Don't Miss: Do windows 10 need antivirus?

Why do people prefer HTTPS protocol for GIT?

Ans:

  • It is easiest to set up on the widest range of networks and platforms and is easier for people to get started in a simple and secure way.
  • It is not necessary to generate, copy, or paste ssh keys into the git server provider.
  • It is easier to access and write on repositories from anywhere and you just need account details.
  • HTTPS is a port that is open in all firewalls and does not require to open by doing to firewall settings.
Also read: How to format code in Gmail?

The downside of Using HTTPS

  • The downside of using HTTPS: You have to enter the GitHub password every time you push. But you can set it to store it permanently using windows credentials in the windows machine. So the credential.helper will cache your password with an HTTPS link. However, if the user changes their password, they must reconfigure everything from scratch visit here
  • If your github/bitbucket/GitLab account (username and password) is stolen then your GitHub/bitbucket/GitLab account can be changed and blocked by them from accessing all your git repositories and even can delete all your repositories.

If you have two-factor authentication enabled(2FA), you will have to use a personal access token(PAT) instead of your regular standard password. If you have enabled Two Factor Authentication, git will prompt you to have a code on your mobile devices or send it as a text message after successfully entering your username and password.

PAT-based authentication is considered to be more secure than password-based authentication. Here, we treat the PAT token as a password. Click here for creating a PAT token in GitHub.

Precaution:

  • Use a strong password.
  • Don't compromise your git account.

Git With SSH

Git used SSH protocol to securely transfer repository data over the internet. Uses public key encryption to secure data.

Git with HTTPS uses public-key encryption-based authentication for doing every action like git push, git clone, git fetch and git pull, etc.

ssh configuration in github

If the links show origin git. .. then you are using an SSH link.

To use SSH URLs, you must generate an SSH keypair on your computer and keep a private key yourself, and add the public key to your GitHub account.

If you want to use SSH URLs, then at the time of git clone, git fetch, git pull or git push to the remote repository, then it will prompt for a password and just must just provide your SSH key passphrase.

Why do people prefer SSH protocol for GIT?

Ans:

  • Using the key is more secure than using a password.
  • No repetitive authentication is required as with HTTPS. For every action that you perform, SSH removes the burden of authenticating on your remote server for every action (clone/push/pull) in git. This is one of the major reasons why SSH prefers to HTTPS.
  • Since you do not have a password for SSH so do not require two-factor authentication. Whoever has your private key can push to your repositories without needing a code-generating device.
  • If your private key is stolen, someone can do a force push to new empty repositories and remove all change records and history for every repository you have, but they (who have stolen) cannot change anything in your GitHub account. This would be much easier to attempt to restore your GitHub account from this hack.
  • SSH seems to be more secure than HTTPS as it does not use password-based authentication.
  • I only use SSH between my own systems because it is far easier to configure securely than mutually authenticated HTTPS.
  • If you use Multi-Factor Authentication(MFA) on Github, and it's a bit of a pain to get HTTPS working correctly and securely on Linux without a desktop environment. SSH completely avoids this problem.
  • SSH, once configured, allows for quick on-the-fly connections to all applications and devices.

  source:github link

The downside of Using SSH

  • One minor drawback is that all connections require authentication, so you always need Github account -even for cloning and pulling repositories but you can store a key so that it will not ask.
  • Networks and Firewalls sometimes refuse to totally allow SSH connections. This makes developers irritated. But must of the case this does not occur. Even If refuse SSH port access then also firewalls allow easy to configure SSH to work over HTTPS.
  • Initial Setup and configuration are a little time-consuming.

Precaution:

  •  use SSH with a passphrase protected key

FAQ:

Are SSL and HTTPS the same?

Ans: HTTPS and HTTP are communication protocols and SSL helps to encrypt and secure that communication channel. TLS is the modern version of SSL.

If data is to be transferred over a communication channel using HTTPS, the first SSL session is established, then all data are bundled into secured SSL or TLS packets before sending and after receiving.

Are SSL and SSH the same?

SSH stands for Secure Shell. SSL stands for Secure Socket Layer. Both are used for secure and reliable connections. These are two important security features used to conduct today's business on the internet.

  • SSL is used to encrypt communication between browser and Server.SSH is used to encrypt communication between any two computers.
    One may be a server and another client.
  • Authentication in SSL is done via public/private key pair. And in SSH, most of the cases it is done through UserId/Password Pair.
  • SSH provides additional features like providing multiple data channels to its application, supports execution of remote programming, TCP IP connections, can issue commands, etc.
Is HTTPS safer/secure than SSH?

Ans: In my view, ssh seems to be more secure and safer than HTTPS because SSH does not use password-based authentication as Https Does. And Password-based authentication seems to be more vulnerable to hackers because humans generally used the same password everywhere on multiple sites, which may result in many vulnerabilities.

So, if SSH keys matter, if proper guidelines for securing SSH are followed then the SSH key generally seems to be more secure.

This is a broad topic, I am just giving my view.

What is git ssh URL?

Actually, there are two types of URLs in your git repository. They are HTTPS URL and SSH URL.

HTTPS Url Looks like this:

https://github.com/helloworld/helloworld.git

Git Url looks like this:

git@github.com:helloworld/helloworld.git
Is SSH faster than HTTPS for git?

Ans: It depends on the amount of latency between your system and the remote server. It is true that for setup ssh connections, doing a DNS lookup, making TCP connections, and authenticating takes a longer time in SSH protocol as SSH is a complex protocol.

According to GitHub git, it is said that HTTPS is slightly faster than SSH in a high-latency network. (source)