4 ms·

Ask a provider like GitHub and Heroku which git protocol they prefer: SSH or HTTPS. The answer is HTTPS. Managing an SSH server with millions of customer pubk

Ask a provider like GitHub and Heroku which git protocol they prefer: SSH or HTTPS. The answer is HTTPS. Managing an SSH server with millions of customer pubkeys is a pain. Python/twisted and Go have decent SSH implementations but there are quirks and side effects a plenty. Shells are scary. You have to be very careful about how you execute the program on the remote side of the pipe. Shell command parsing and escaping is gnarly. Windows... HTTPS with basic auth headers is much easier to scale. The one gotcha is that it took a while for HTTP git to get "smart" and offer as efficient transport as SSH with access to a .git dir.

technomancy 11y ago
It's not as simple as you make it out to be. HTTPS git still has no consistent way to cache credentials, so you're stuck either keeping it in plaintext on disk or re-authenticating every time you push. Even though client TLS certs are technically supported by a handful of services, there's nothing for HTTPS that matches the security and convenience of ssh-agent. It has a long way to go to catch up to where SSH was ten or fifteen years ago.
- tadfisher 11y ago
  git supports "credential helpers" [0] which allow arbitrary credential storage and retrieval schemes. I've successfully used it with a Yubikey, for example, although I promptly reverted to using SSH and my GPG authentication subkey when it became clear that there is no single scheme that works on all platforms I use. [0] https://git-scm.com/docs/git-credential https://git-scm.com/docs/git-credential
  - nzoschke 11y ago
    The parent has a great point about credentials and ssh-agent in general. Netrc isn't a great pattern. But for git you have the right answer. I completely forgot this aspect because on OS X you can delegate git auth to Keychain with a helper. https://help.github.com/articles/caching-your-github-password-in-git/ https://help.github.com/articles/caching-your-github-passwor...
    - technomancy 11y ago
      Apparently since the last time I checked, git actually includes a helper script that allows you to use `gpg-agent` to decrypt your creds in an analogous way to how `ssh-agent` works. It requires a bit of setup since for some reason it's disabled by default, and it's a bit more moving parts (GPG key plus username/password instead of a single keypair) but it's a lot better than it used to be. I hope this pattern catches on for services other than git.
      - tadfisher 11y ago
        A better solution is to simply use `gpg-agent` as your `ssh-agent`, as it supports that protocol and it supports RSA authentication keys. Then your public keys provide not only identity, but services can verify that identity through their web of trust.
chopin 11y ago
I prefer ssh for this purpose since I don't want to store credentials somewhere in plain text.
- ryanlol 11y ago
  Why would you do that with either option?
  - pritambaral 11y ago
    HTTPS auth provided by Github et al. don't support client certs, only username/password pairs. There is no equivalent to ssh-agent for HTTPS (because authenticating to HTTPS URLs is not a standard).
    - ryanlol 11y ago
      I still don't see why that'd require storing of plaintext credentials.
pritambaral 11y ago
> millions of customer pubkeys is a pain And millions of passwords isn't because ... ? Whatever solution the industry has arrived at for storing a large number of user passwords and authenticating against them, can be applied to SSH keys too. I would be greatly suprised if Github uses ~/.ssh/authorized_keys to handle SSH authentication at its scale. > Python/twisted and Go have decent SSH implementations but So is the case with HTTPS implementations. It's just a standard, how it's implemented is not under its control. On the other hand, we have some good implementations of HTTPS, and similarly we have good implementations of SSH too: libssh2. > Shells are scary. So don't use shells over the SSH protocol. Make the server execute (upon successful auth) something that isn't a shell. > Windows... Agreed. Until user-agents popularly support a protocol, adoption faces large obstacles. > HTTPS with basic auth headers is much easier to scale Easier how? You have to do less computation to verify the password? This has nothing to do with the transport, and everything to do with the cryptographic strength of the password. SSH is better here because of its good support of keys (versus TLS client certs).

technomancy 11y ago

It's not as simple as you make it out to be. HTTPS git still has no consistent way to cache credentials, so you're stuck either keeping it in plaintext on disk or re-authenticating every time you push. Even though client TLS certs are technically supported by a handful of services, there's nothing for HTTPS that matches the security and convenience of ssh-agent. It has a long way to go to catch up to where SSH was ten or fifteen years ago.

tadfisher 11y ago
git supports "credential helpers" [0] which allow arbitrary credential storage and retrieval schemes. I've successfully used it with a Yubikey, for example, although I promptly reverted to using SSH and my GPG authentication subkey when it became clear that there is no single scheme that works on all platforms I use. [0] https://git-scm.com/docs/git-credential https://git-scm.com/docs/git-credential
- nzoschke 11y ago
  The parent has a great point about credentials and ssh-agent in general. Netrc isn't a great pattern. But for git you have the right answer. I completely forgot this aspect because on OS X you can delegate git auth to Keychain with a helper. https://help.github.com/articles/caching-your-github-password-in-git/ https://help.github.com/articles/caching-your-github-passwor...
  - technomancy 11y ago
    Apparently since the last time I checked, git actually includes a helper script that allows you to use `gpg-agent` to decrypt your creds in an analogous way to how `ssh-agent` works. It requires a bit of setup since for some reason it's disabled by default, and it's a bit more moving parts (GPG key plus username/password instead of a single keypair) but it's a lot better than it used to be. I hope this pattern catches on for services other than git.
    - tadfisher 11y ago
      A better solution is to simply use `gpg-agent` as your `ssh-agent`, as it supports that protocol and it supports RSA authentication keys. Then your public keys provide not only identity, but services can verify that identity through their web of trust.

chopin 11y ago

I prefer ssh for this purpose since I don't want to store credentials somewhere in plain text.

ryanlol 11y ago
Why would you do that with either option?
- pritambaral 11y ago
  HTTPS auth provided by Github et al. don't support client certs, only username/password pairs. There is no equivalent to ssh-agent for HTTPS (because authenticating to HTTPS URLs is not a standard).
  - ryanlol 11y ago
    I still don't see why that'd require storing of plaintext credentials.

pritambaral 11y ago

> millions of customer pubkeys is a pain And millions of passwords isn't because ... ? Whatever solution the industry has arrived at for storing a large number of user passwords and authenticating against them, can be applied to SSH keys too. I would be greatly suprised if Github uses ~/.ssh/authorized_keys to handle SSH authentication at its scale. > Python/twisted and Go have decent SSH implementations but So is the case with HTTPS implementations. It's just a standard, how it's implemented is not under its control. On the other hand, we have some good implementations of HTTPS, and similarly we have good implementations of SSH too: libssh2. > Shells are scary. So don't use shells over the SSH protocol. Make the server execute (upon successful auth) something that isn't a shell. > Windows... Agreed. Until user-agents popularly support a protocol, adoption faces large obstacles. > HTTPS with basic auth headers is much easier to scale Easier how? You have to do less computation to verify the password? This has nothing to do with the transport, and everything to do with the cryptographic strength of the password. SSH is better here because of its good support of keys (versus TLS client certs).