Do you clone Git repos via HTTPS or SSH?

lostintangent profile image Jonathan Carter ・1 min read

Hey All! Random question: when you clone a Git repo, do you use HTTPS or SSH to do it? Furthermore, is your decision based on a specific reason (e.g. HTTPS is traditionally easier on Windows?, team policy?), or mostly just habit (e.g. you've already got an SSH key so why not re-use it! 🚀, that's what GitHub shows by default)? I've noticed a diverse set of opinions across folks I know, and I'm mostly just curious about others' usage in-the-wild.


markdown guide

Been cloning them using HTTPS for a long time and just at the end of last year started doing it with SSH. And boy is like one of those things when once you experiment it, you'll never go back to the other way again.


The whole point of the discussion is tell why do you use one over another.


I'm doing more dotnet core lately and often switch between macOS and Windows - HTTPS with the git credential manager is straightforward. The first clone starts an OAuth flow which stores the token in your OS key store and then you're done. You can revoke keys in DevOps or Github, etc. So much faster than SSH IMO.


thats what I like about https no hassle to generate keys and paste them in github. I think too lazy for that, just save my password.


Safe to assume you're not doing signed-commits, then?

no, is there any benefit of signed commits?

Primarily attribution: with signed commits, you generally know that the person listed as the commit-author was actually the person who uploaded the commit (since, presumably, they're the only person with access to the [presumably] password-protected GPG key used to sign the commit). Combined with other security-measures, it's a good way to ensure that no nasties get into your git project (and better auditing if something actually does).

I use GPG keys at work

but I never get how GPG keys are more secure than password.

How they are any harder to get than passwords?

because I'm the only person who knows my password, and both are compromised if the attaker gets access my desktop.

"Defense in depth"

Much like, if you have encrypted volumes on your desktop/laptop, you set a different password for encrypted volumes than for your login password, you set a different password for your GPG keys than your login password.

Similarly, you don't have to keep your GPG keys on your desktop/laptop: you can write them to an encrypted device (like a Yubikey). That way, an attacker:
1) Needs the physical device
2) Needs the unlock credentials for the device
3) Needs the password for the GPG key

Presumably, by the time an attacker has surmounted #3, you've invalidated the errant GPG key. Even with a GPG key on an unencrypted disk/device, attacker needs to gain access to the device and then brute-force the password on the key. And, again, presumably by the time they've managed to break the key, you've invalidated it.

thanks for taking the time to tell my that, now I get that.


Unfortunately the default credential "manager" in Linux seems to be storing to a plaintext file.


SSH. Along with ~/.ssh/config so it's easy to manage work vs personal keys, etc.

I tend to use the same key-pairs when I setup key-based auth between my various machines- which I'm a huge proponent of.


ssh whenever I can...
(passwordless connection using key is so convenient)


SSH Key because I have 2FA and HTTPS doesn't usually work well with it and second strong point is I am too lazy to input the pwd every time.


I think git for windows uses windows credential manager so I only need to enter password once per git install or if I want to change my github profile


I use Linux about 99% of the time when dealing with Git, so I've long since been in the habit of using SSH for almost all Git usage. The only times I use HTTPS are cases where I need read-only access to a repo that doesn't support SSH access.

Realistically though, I originally started using SSH for the following three reasons:

  • I use MFA on Github, and it's a bit of a pain to get that working correctly and securely on Linux without a desktop environment. SSH completely bypasses that issue.
  • Unlike HTTPS, SSH cloning uses Git's native protocol. This translates to somewhat more efficient cloning in many cases. This doesn't matter in many cases, but when you're dealing with repos with lots of history (for example, the Linux kernel sources) on a slow connection, it can make a significant difference.
  • I only use SSH between my own systems because it's exponentially easier to set up securely than mutually authenticated HTTPS.

For my Windows setup, I have configured git to automagically replace HTTPS with SSH on the fly:
git config --global url.ssh://git@github.com/.insteadOf github.com


I do SSH, since I like managing my own SSH key.

But when I am helping new co-workers get setup I ask if they like managing SSH keys, if they don't want to or don't know what I'm talking about I setup HTTPS. It's the easier and "just works" option, at least on platforms with a good credential store, to store the access token needed for HTTPS login


https - coming from a Windows background it was simpler


SSH on Linux, Mac and Windows


HTTPS when I must (read-only or public GitHub) otherwise SSH (all pushes).
Cross platform, consistent, manageable, no plugins needed.
In Windows, GIT_SSH=C:\PuTTY\plink.exe and add my *.ppk key file (associated with Pagent) to the "Startup" folder in my user profile.


I just copy whatever URL the "Clone or download" button on GH gives me :D Usually it's SSH on your own repos, HTTPS on other people's


HTTPS on Windows mostly but I do have SSH set up on another machine.


I don't think I've ever paid attention to this. Granted, I'm lazy, and I've been using the GUI.


Prefer SSH, it's just matter of personal preference, there's pros and cons for both of them of course.
But with SSH and keys it's lot easier


How? With the git credential manager, the oauth/access token is stored in the OS' native key store and you don't have to worry about sshkeygen, uploading keys, etc, etc.


I work on Windows and the https urls used to be a bit of a pain w/ Credential Manager, so I've always used ssh with gitbash.


I use HTTPS mainly because never tried SSH - but will give it a go next time.


SSH from the very beginning using the ".ssh/config" file for different keys and servers. I use HTTPS obly as a workaround when the SSH ports are blocked for example.


SSH. Intuitive and once set up, easy on the fly connection to all applications and devices I use.


I've used HTTPS for years and switched quite recently to SSH because I got bored of typing a password. My laziness always win.


SSH for osx and linux. Used to do https on Windows but now that SSH support is built in I use SSH there to.


I've only ever willingly done via SSH. Mostly, when I'm doing HTTPS, it's because the repo-maintainer doesn't provide me the option for SSH.


I usually clone public repos over HTTPS and have pushInsteadOf in my git config to always push over SSH. I clone private repos over SSH.


ssh by configuring cert
don't prefer https because I don't like to put username and password everytime.


Most recent git client implementations let you use a credential manager with configurable caching TTLs.


I've stuck to HTTPS because it works and I don't have to put much thought to it. I honestly haven't tried to use SSH for Git in years


I have shared my config folder between all my machines so that I never have to login to do stuff. Ssh is magic with small upfront investment.


SSH as it's much easier when you use 2FA