Do you clone Git repos via HTTPS or SSH?

Jonathan Carter on June 10, 2019

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.... [Read Full]
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.


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?

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)


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


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.

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.


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


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 - coming from a Windows background it was simpler


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


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.


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.


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.


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.


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've used HTTPS for years and switched quite recently to SSH because I got bored of typing a password. My laziness always win.


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


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.


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 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 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


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.

code of conduct - report abuse