But the hard part is getting everybody to support this. We need to start somewhere. Maybe GitHub can use this bad publicity and turn this into one good
If you're doing TLS then you might as well do HTTPS. GitHub already supports HTTPS and way more features for it than SSH, and HTTPS works over more networks than SSH does. Continuing to use SSH is literally just being obsessed with a backwards old protocol for nostalgia reasons.
Honest question:
Client authorization (for private repos) is an important feature of SSH.
How does this work with HTTPS?
EDIT: I just remembered the existence of TLS client certificate authentication. I wonder if it's possible to use an SSH client key for this (making the server accept a self-signed client certificate from the list of keys in authorized_keys).
This is a good point actually. It's kinda funny how even Microsoft's own GUI IDE uses an underlying ssh protocol with ssh keys that the end user doesn't even need to see or know about.
Now that we're mostly using ssh to push source code, or connect to remote systems, why not just use tls instead? Aside from its general availability, feels like inevitable.
As it is, I‘d argue that straightforward protocol layer client public key authentication is one of the biggest benefits of using SSH, although I do wish X509/PKI server authentication could optionally be used with it.
I disagree, it seems not straightforward at all.
First as a user you have to generate a key. You need to install software and look up a manual. Then you have to give a server admin your public key, which for many users is often confused for the private key and thus defeats the purpose. Then when you connect to the server you have to manually validate the host fingerprint, which again requires more commands and documentation.
The alternative (in HTTPS) is to use Let's Encrypt on the server, and enable HTTP Basic authentication from either a web server or a reverse proxy. The admin gives the user their login and the client just connects.
With those two features you get 1) strong encryption that your user does not need to manually validate, and 2) a non-bruteforceable authentication token. Not only that, but it's compatible with a thousand other applications and modifiable in a million ways.
I think an ideal solution would offer some hybrid of TOFU and PKI for server authentication, and self-signed keys for client authentication (like FIDO and WebAuthN, for example), but at the protocol level.
HTTPS really falls short here and means that everybody has to implement something custom on top of it, and too often that is a login form driving OAuth.