- An SSH key can be revoked on the server, but the client won't register it immediately, and all clients must manually verify the new key signature and update their local configuration. This doesn't happen with HTTPS; the client just works with the server's new cert, no user intervention is required.
- A username can be used in the HTTPS URI to tell both your client and the server what credential to use. SSH method requires the user to load the correct SSH key first.
- Most servers like GitHub allow more fine grained access control for HTTPS tokens than SSH keys.
- HTTPS access method works on all HTTP proxies, whereas SSH is often blocked.
- HTTPS can be faster than SSH.
- HTTPS allows a client and server to use specific ciphers to address regulatory and other requirements.
- HTTPS tokens are supported in a wider range of password managers/keychains than SSH keys.
- Most users don't password protect their SSH keys, but they often have a password manager with a master password that they can keep HTTPS token in.
- SSH key management is much more complex on the user end than HTTPS token management. The former requires ssh-agent, a key generator, and instructions for use, as well as specific filesystem permissions for keys.
- The user often doesn't understand the idea that they shouldn't share their private key. But everyone basically gets they shouldn't share their password.
- Virtually no one ever checks the fingerprint of ssh server keys. Often entire companies have configuration that disables host key checking, completely eliminating the security SSH is supposed to provide. With HTTPS the user is implicitly protected with no actions necessary.
- Nobody ever commits a private TLS key to a GitHub repo, but apparently they do with SSH private keys...