Hacker News Reader

Comment by cpitman | Hacker News Reader

I had never noticed before that GitHub "Highly Recommends" cloning via HTTPS instead of via SSH. This is the opposite of what I usually tell people to do. I do not see any reasoning anywhere, but I might have missed it.

Does anyone know why you would recommend HTTPS over SSH? Is it just the complication of setting up SSH keys?

View on HN

Yes, they've explained elsewhere that they prefer HTTPS because you can use your GitHub credentials. HTTPS should be secure but SSH is my preference as well.

In addition to corporate firewalls, it isn't uncommon for all ports other than 80 and 443 to be blocked in public wifi environments.

> This is the opposite of what I usually tell people to do

How come, out of interest? In terms of peformance, cloning for HTTP is fairly efficient these days although I would concede an authentication argument.

(As an aside, SSH can be blocked on some corporate networks)

I much prefer to use an ssh key for auth than copypasta'ing the same passphrase I use in my browser.

Because you don't have to keep supplying credentials when using SHH keys. It's less about speed and more about reducing the friction in common operations. It's also the way I'm used to handling things with gitolite, so that might be part of it.

We already usually use SSH w/ keys for server access, so uploading public keys to GitHub isn't much of an additional hurdle.

You can setup a credential manager in git and don't have to continue supplying credentials with HTTPS repositories. For instance, I commonly use this one on Windows [1]:

https://github.com/Microsoft/Git-Credential-Manager-for-Wind...

[1] Although currently marked as pre-release, this is a fork/successor of an earlier one that was fairly rock solid, now with a better installer. The "pre-release" tag here mostly is with respect to the new 2FA support.

Thanks, but this seems like a lot more complexity than using github's built-in SSH Key manager (especially since I wager that most people using github are not on windows). That, and I've inevitably always needed SSH keys for one thing or another on every computer I've used, so it's just really streamlined.

As with most such things, your mileage will of course vary. There are credential managers out there for things like the the Mac OS X keychain and Gnome keyring.

So yes, if you've already got SSH keys in play and you aren't dealing with (corporate) firewall issues for SSH protocols then that is often going to be convenient, but the point is that credential managers are out there and are equally convenient (work just like the ssh-agents you rely on) for those (stuck) with HTTPS or who don't need SSH keys anywhere other than git(hub) repositories.

Also, I'd almost take that wager. There are a lot of Windows developers these days on Github and/or Github for Enterprises. I don't think Windows developers have made it into a majority yet, but I'm guessing there are a lot more than you think there are.

SSH is blocked on some corporate firewalls, they've said before that they've implemented HTTPS support to get around this.

I can think of one possible reason: if you have a passphrase on your SSH key (which GitHub recommends in their keygen tutorial) then pulling from a repo will require you to enter your passphrase, which is somewhat silly if you have some remotes that you only pull from and never push to (and of course you can set up different remotes for pushing and pulling for the same alias, but I've rarely seen that done).

Their tutorial[0] also recommends using ssh-agent which means you'll only need to enter your passphrase once, and it integrates with your OS keychain.

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

I always recommended ssh until trying to use gitlab for a class I teach to nonprogrammers... and the extra complication over https was immense. Lots of github's users have never used SSH before and those that are comfortable with it probably aren't going to pay attention to github's recommendation anyway.

For example - ports other than 443 and 80 are more often blocked.

Reply on news.ycombinator.com