439

On the GitHub site there is a link...

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

... and it states...

If you have decided not to use the recommended HTTPS method, we can use SSH keys to establish a secure connection between your computer and GitHub. The steps below will walk you through generating an SSH key and then adding the public key to your GitHub account.

Why is HTTPS the recommended method? Is there some sort of security flaw in the SSH method or is it slower? I created an SSH key, so would that mitigate any security concerns?

lofidevops
  • 13,448
  • 13
  • 75
  • 107
John Livermore
  • 28,549
  • 42
  • 117
  • 207
  • 55
    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
  • 4
    SSH URLs used to be the default ones, but now HTTPS ones are. – Fred Foo Jun 14 '12 at 21:40
  • 1
    Perhaps they have a TLS-accelerator card that can reduce CPU load if their users are using HTTPS? – sarnold Jun 14 '12 at 21:41
  • 90
    To future users who find this thread: GitHub has changed their policy and now says "We strongly recommend using an SSH connection when interacting with GitHub." – beardedlinuxgeek Mar 23 '14 at 15:25
  • 3
    For the "strongly recommend" statement from GitHub, see https://help.github.com/articles/generating-ssh-keys – Steve Pomeroy Mar 28 '14 at 17:41
  • I think that the question could be edited, because people should know the new official policy without diving into comments. – cubuspl42 Jul 16 '14 at 22:59
  • 10
    @StevePomeroy, I don't think the "strongly recommend" statement exists at that location. – Noel Abrahams Aug 27 '14 at 12:43
  • 1
    @beardedlinuxgeek could you provide a reference for that? – BonsaiOak Sep 28 '14 at 21:49
  • 6
    @BonsaiOak It used to be on the page Steve Pomeroy linked to - http://web.archive.org/web/20140321204642/https://help.github.com/articles/generating-ssh-keys - but it looks like they changed it since then. – beardedlinuxgeek Sep 30 '14 at 18:18
  • 3
    @beardedlinuxgeek, on their [help pages](https://help.github.com/articles/which-remote-url-should-i-use/) they still recommend the use of HTTPS over SSH – br3nt Jan 14 '16 at 00:40
  • 6
    @br3nt Right. They used to not recommend it. Then they did. Then they didn't again. That's why my link is to an archive.org page – beardedlinuxgeek Jan 15 '16 at 03:36
  • 1
    Reading the comments and answers now (April 2016) left me confused about the recommended access. According to this newer page - https://help.github.com/articles/which-remote-url-should-i-use/ - they currently recommend https (though they don't say why). – noamtm Apr 27 '16 at 06:53
  • Stack Overflow is a site for programming and development questions. This question appears to be off-topic because it is not about programming or development. See [What topics can I ask about here](http://stackoverflow.com/help/on-topic) in the Help Center. Perhaps [Unix & Linux Stack Exchange](http://unix.stackexchange.com/) or [Information Security Stack Exchange](http://security.stackexchange.com/) would be a better place to ask. – jww Oct 09 '17 at 15:23

7 Answers7

272

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://help.github.com/articles/which-remote-url-should-i-use/

    The https:// clone URLs are available on all repositories, public and private. These URLs work everywhere--even if you are behind a firewall or proxy.

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

    https://help.github.com/articles/set-up-git

    Good to know: The credential helper only works when you clone an HTTPS repo URL. If you use the SSH repo URL instead, SSH keys are used for authentication. While we do not recommend it, if you wish to use this method, check out this guide for help generating and using an SSH key.

omerfarukdogan
  • 819
  • 9
  • 25
k107
  • 14,993
  • 7
  • 58
  • 58
  • 76
    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
  • 95
    @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
  • 10
    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
101

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.

jr0cket
  • 1,667
  • 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. – jr0cket 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. – jr0cket Jun 22 '20 at 19:44
17

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
  • 771
  • 7
  • 9
  • 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
  • 1
    Now they completely removed that quote. – Onat Korucu May 08 '21 at 21:22
15

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.

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 your ssh config, edit the file at ~/.ssh/config, and add this section:

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

You can test that this works by connecting once more to GitHub:

$ ssh -T git@github.com
Hi username! You've successfully authenticated, but GitHub does not
provide shell access.

From Authenticating to GitHub / Using SSH over the HTTPS port

mja
  • 1,075
  • 1
  • 16
  • 22
11

Also see: the official Which remote URL should I use? answer on help.github.com.

EDIT:

It seems that it's no longer necessary to have write access to a public repo to use an SSH URL, rendering my original explanation invalid.

ORIGINAL:

Apparently the main reason for favoring HTTPS URLs is that SSH URL's won't work with a public repo if you don't have write access to that repo.

The use of SSH URLs is encouraged for deployment to production servers, however - presumably the context here is services like Heroku.

Mark Tye
  • 1,643
  • 16
  • 10
  • 2
    "These URLs provide access to a git repository over SSH. To use these URLs, you must have write access to a public repository or any access to a private repository. These URLs will not work with a public repository you do not have write access to" - THIS IS NOT TRUE. Anyone can clone a public repo with an SSH url they do not have write access to – Sam Jun 07 '13 at 05:38
  • 1
    @Sam It may not be true anymore, but was true when I answered the question. I have edited my answer to reflect the change. – Mark Tye Jun 28 '13 at 18:40
  • Indeed. The question "How does GitHub recommend HTTPS over SSH" would be nonsensical. – Mark Tye Sep 24 '13 at 00:03
1

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,800
  • 1
  • 35
  • 36
  • 4
    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
  • 825
  • 8
  • 16