Why does GitHub recommend HTTPS over SSH?

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?

GitHub have changed their recommendation several times (https://web.archive.org/web/20140321204642/https://help.github.com/articles/generating-ssh-keys">example</a>;).

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.

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.

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

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 [email protected] 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

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.

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.

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.