462

git clone supports both HTTPS and SSH remote URLs. Which should I use? What are the advantages of each?

GitHub's docs don't make a recommendation either way. I recall in 2013 GitHub used to recommend SSH (archive link). Why was that?

Colonel Panic
  • 132,665
  • 89
  • 401
  • 465
John Livermore
  • 30,235
  • 44
  • 126
  • 216
  • 59
    Less configuration means easier, perhaps. Besides, some inferior operating systems don't even have SSH clients installed by default. – katspaugh Jun 14 '12 at 21:40
  • 1
    # Enabling SSH connections over HTTPS if it is blocked by firewall Test if SSH over the HTTPS port is possible, run this SSH command: $ ssh -T -p 443 git@ssh.github.com Hi username! You've successfully authenticated, but GitHub does not provide shell access. If that worked, great! If not, you may need to follow our [troubleshooting guide](https://help.github.com/articles/error-permission-denied-publickey). If you are able to SSH into `git@ssh.github.com` over port **443**, you can override your SSH settings to force any connection to GitHub to run though that server and port. To set this in yo – mja Jan 18 '18 at 05:18

7 Answers7

287

GitHub have changed their recommendation several times (example).

It appears that they currently recommend HTTPS because it is the easiest to set up on the widest range of networks and platforms, and by users who are new to all this.

There is no inherent flaw in SSH (if there was they would disable it) -- in the links below, you will see that they still provide details about SSH connections too:

  1. HTTPS is less likely to be blocked by a firewall.

    https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls

    The https:// clone URLs are available on all repositories, regardless of visibility. https:// clone URLs work even if you are behind a firewall or proxy.

  2. An HTTPS connection allows credential.helper to cache your password.

    https://docs.github.com/en/get-started/quickstart/set-up-git#connecting-over-https-recommended

    If you clone with HTTPS, you can cache your GitHub credentials in Git using a credential helper. For more information, see "Cloning with HTTPS urls" and "Caching your GitHub credentials in Git."

bleuthoot
  • 75
  • 1
  • 7
k107
  • 15,882
  • 11
  • 61
  • 59
  • 81
    Ah, so they recommend HTTPS simply so they don't have to document `ssh-agent`? Fair enough. Thanks! – sarnold Jun 14 '12 at 21:48
  • 102
    @sarnold It probably has more to do with the volume of questions related to ssh-agent and public key management, and the number of corporate firewalls that allow outbound HTTP/HTTPS but not SSH. – Todd A. Jacobs Jun 14 '12 at 21:55
  • 7
    I think that https makes it easier for people to get started since you don't have to do the whole generate/copy/paste ssh key business. Also it could be viewed as more secure from Github's perspective since an attacker who got your ssh password (or found a computer terminal you left open) would still have to know your Github password to push anything. – k107 Jun 15 '12 at 18:52
  • 5
    @kristi If the attacker finds that terminal before the password cache expires, wouldn't he still be able to push even if he don't know the password? The question is about the same if you use ssh-agent, the obvious difference being that you have to enter the password of the ssh key instead of your github password (and there seems no obvious setting for cache expiration). The idea of entering the github password instead of ssh key password seems a step backwards, albeit a small one since the power the two keys give you are about the same AFAIK. – Halil Özgür Jun 16 '12 at 11:05
  • 1
    Though I agree that the github password method is much easier than the whole ssh key thing (especially if you are not on linux). – Halil Özgür Jun 16 '12 at 11:10
  • 11
    I think it's almost entirely about reducing the volume of support queries they get. I suppose you could also argue that since you *have* to enter your password over HTTPS anyway to access the website, you can't be *increasing* security by using a different authentication mechanism (SSH keys), but feasibly you're increasing the attack surface which might *decrease* security. Still, both HTTPS and SSH should be adequately secure if used properly. – Cartroo Jan 16 '13 at 12:31
  • 1
    Wouldn't SSH be more secure as instead of just having to have/crack/steal a password it is machine based? – kdbdallas Mar 21 '13 at 18:35
  • 1
    @CodeGnome is correct, GitHub uses those same reasons when discussing advantages of HTTPS here: https://help.github.com/articles/why-is-git-always-asking-for-my-password#why-not-use-https – Dennis Jul 14 '13 at 02:08
  • 2
    @kristi They created the credential helper for better support for the https. This doesn't answer *why* in the first place Github prefers https to ssh. – dolmen Sep 20 '13 at 13:06
  • Keep in mind that all credential helpers must store your GitHub password in a way that can it can be retrieved in cleartext, and on some (most?) systems (e.g. [Windows](https://github.com/0cjs/sedoc/blob/master/git/win.md#credential-management) this is trivial to do for anybody who can use your account for a brief moment. Using a [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/) will help, and adding [2FA](https://help.github.com/articles/about-two-factor-authentication/) on top of that is always a good idea. – cjs Aug 08 '18 at 09:03
  • 1
    This answer helped me a lot as it points out that firewalls can block SSH communication. I was getting a broken pipe error in terminal when trying to push a project to github, the reason is that I was on a new wifi network which apparently had a firewall. After switching to a new wifi network, I was able to use SSH again. – James Hubert Nov 27 '19 at 19:03
  • 1
    Web is running on https, APIs are running on https, the world is running on https, why not Git too? – Joan Sep 17 '20 at 07:42
112

I assume HTTPS is recommended by GitHub for several reasons

  1. It's simpler to access a repository from anywhere as you only need your account details (no SSH keys required) to write to the repository.

  2. HTTPS Is a port that is open in all firewalls. SSH is not always open as a port for communication to external networks

A GitHub repository is therefore more universally accessible using HTTPS than SSH.

In my view SSH keys are worth the little extra work in creating them

  1. SSH Keys do not provide access to your GitHub account, so your account cannot be hijacked if your key is stolen.

  2. Using a strong keyphrase with your SSH key limits any misuse, even if your key gets stolen (after first breaking access protection to your computer account)

If your GitHub account credentials (username/password) are stolen, your GitHub password can be changed to block you from access and all your shared repositories can be quickly deleted.

If a private key is stolen, someone can do a force push of an empty repository and wipe out all change history for each repository you own, but cannot change anything in your GitHub account. It will be much easier to try recovery from this breach of you have access to your GitHub account.

My preference is to use SSH with a passphrase protected key. I have a different SSH key for each computer, so if that machine gets stolen or key compromised, I can quickly login to GitHub and delete that key to prevent unwanted access.

SSH can be tunneled over HTTPS if the network you are on blocks the SSH port.

https://help.github.com/articles/using-ssh-over-the-https-port/

If you use HTTPS, I would recommend adding two-factor authentication, to protect your account as well as your repositories.

If you use HTTPS with a tool (e.g an editor), you should use a developer token from your GitHub account rather than cache username and password in that tools configuration. A token would mitigate the some of the potential risk of using HTTPS, as tokens can be configured for very specific access privileges and easily be revoked if that token is compromised.

practicalli-john
  • 1,836
  • 1
  • 12
  • 8
  • 4
    "although if someone does get hold of your private key they can do a force push of an empty repository and wipe out your change history" - yes (and would be awful), but the beauty of distributed codebases allows us to recover with someone who has a copy of it at least. – Cameron Jan 24 '17 at 21:15
  • 2
    I'm not sure stating that someone being able to force push is a differentiator between SSH and HTTPS. If I had your username and password, I could equally force push. – Matt Canty Jul 04 '19 at 08:18
  • 2
    If you have username & password you can delete everything (after changing the password and email contact of course). No need to do individual force push on each repository if you can just delete them. – practicalli-john Jul 05 '19 at 09:36
  • you are comparing password vs ssh key while https connection requires a special token. – Alexey Sh. May 29 '20 at 09:26
  • 1
    HTTPS does not require a developer token, just username and password (and 2FA if its enabled on the GitHub account). I would recommend the use of a token over username/password. A developer token has less inherent risk as it can be configured for specific access, does not use the GitHub account password and is revocable if compromised. – practicalli-john Jun 22 '20 at 19:44
  • As of August 13, 2021 they no longer support password login over HTTPS. You have to generate and use an access token (which I assume will be cached by your credentials manager). That kind of makes using SSH the less cumbersome choice, since creating tokens is quite a hassle (and it's not very clear for novices exactly what permissions such a token should have). – Adam Lindberg Jun 15 '22 at 12:16
18

Either you are quoting wrong or github has different recommendation on different pages or they may learned with time and updated their reco.

We strongly recommend using an SSH connection when interacting with GitHub. SSH keys are a way to identify trusted computers, without involving passwords. The steps below will walk you through generating an SSH key and then adding the public key to your GitHub account.

https://help.github.com/articles/generating-ssh-keys

Sid Sarasvati
  • 819
  • 9
  • 10
  • 28
    FWIW, this page no longer contains the "strongly recommend" text quoted in this answer. – Scott Isaacs Jun 09 '15 at 15:51
  • 1
    The still use "recommended" for HTTPS in the following link: https://help.github.com/articles/which-remote-url-should-i-use/#cloning-with-https-urls-recommended "Cloning with HTTPS URLs (recommended)" – JBE Dec 12 '17 at 20:46
  • 2
    Now they completely removed that quote. – Onat Korucu May 08 '21 at 21:22
  • Thank you to those who removed the quote. Props to all the editors to make sure information is kept up to date. – benhorgen May 30 '23 at 03:00
2

Recommendation: use HTTPS with an OAuth credential helper such as Git Credential Manager or git-credential-oauth.

No more passwords or personal access tokens! The first time you push, the helper will open a browser window to authenticate. Subsequent pushes within storage lifetime require no interaction.

Disadvantages of SSH:

  • Authenticates unnecessarily when cloning or fetching a public repo.
  • SSH client has to be installed.
  • Creating an SSH key is unfamiliar to many new Git users.
  • To protect against man-in-the-middle attacks, the user must manually verify the host fingerprints. Not everyone bothers!
  • Configuring a key with a host involves copy-and-paste between terminal and a website. To use 3 computers with 5 hosts, the user must do this 15 times.
  • SSH keys without a passphrase are stored in plaintext without expiry.
  • SSH key passphrase (if used) has to be typed regularly. Even after configuring ssh-agent, passphrase has to be typed after each system restart.
  • SSH is sometimes blocked by firewalls.

Advantages of HTTPS:

  • No authentication to clone or fetch a public repo.
  • Server authenticity is automatically verified using HTTPS certificate.
  • Assuming you use an OAuth credential helper such as Git Credential Manager or git-credential-oauth, you never have to type a password or configure a personal access token.
    • OAuth protocol protects against token theft by using short-lived tokens and refresh token rotation that detects replay attacks. This is an advantage over personal access tokens.
  • Credentials can be stored in cache or platform-specific storage such as wincred, osxkeychain or libsecret.
Colonel Panic
  • 132,665
  • 89
  • 401
  • 465
  • There is no "canonical answer" though. I worked as a contractor for banking/insurance companies, and I can assure you SSH is out of the picture. And for intranet Git repository service hosting, per [CISO](https://en.wikipedia.org/wiki/Chief_information_security_officer) policy, no OAuth allowed. – VonC May 27 '23 at 18:04
0

It's possible to argue that using SSHs key to authenticate is less secure because we tend to change our password more periodically than we generate new SSH keys.

Servers that limit the lifespan for which they'll honor given SSH keys can help force users toward the practice of refreshing SSH-keys periodically.

benhorgen
  • 1,928
  • 1
  • 33
  • 38
  • 6
    It's now considered bad advice to make users change their passwords periodically. UK Governments view: https://www.ncsc.gov.uk/articles/problems-forcing-regular-password-expiry – nazerb Oct 12 '17 at 13:08
0

One further reason for favoring HTTPS is that if multiple users are managing code on a central server -- say a development machine -- each user needs to create their own ssh key in order to use the SSH-based connection. If the connection is HTTPS, this issue doesn't exist.

I guess you could argue that it's not so difficult to just have setting up your own key be a part of onboarding to using the server where that project is stored, but it is a further hurdle to getting your work done.

tobylaroni
  • 843
  • 8
  • 16
0

There is no "official" Git recommendation for this, but each Git remote host has its own preferences.

For example, the GitHub website and GitHub CLI both default to HTTPS, for "better interoperability and ease of use". GitLab, on the other hand, recommends SSH in its documentation.

There are advantages and disadvantages to both approaches:

  • SSH

    • Advantages
      • Allows for automated authentication without the use of a credentials manager
      • SSH keys are more secure than username and password authentication
    • Disadvantages
      • Firewalls may block port 22, which is used by SSH
      • SSH keys must be managed on every machine that connects to the remote

  • HTTPS

    • Advantages
      • Simpler authentication setup with either a username/password combination or a personal access token
      • Uses port 443, which is rarely blocked by firewalls
    • Disadvantages
      • Less secure than SSH keys
      • Requires re-entering username and password for authentication without the use of a credentials manager

These recommendations have changed over the years for various reasons.

  • Credentials managers and access tokens removed the automation issue with authenticating over HTTPS
  • It's much less common to self-host Git remotes these days. Self-hosting meant that for SSH authentication, all contributors needed SSH access to the host machine, but it was generally easier to setup and secure within a private network
  • The Git protocol, which listens on port 9418, is a rarely used daemon that comes prepackaged with Git. It's the fastest protocol by far, but also considered to be insecure
TonyArra
  • 10,607
  • 1
  • 30
  • 46