> Seems like a pretty way to solve this by having ssh clients check the TLS of the host

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.

>Continuing to use SSH is literally just being obsessed with a backwards old protocol for nostalgia reasons.

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.

If TLS/HTTPS supported self-signed client certificates I could sympathize a bit more with this viewpoint.

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.

> straightforward protocol layer client public key authentication is one of the biggest benefits of using SSH

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.

Agreed on all points about self-signed key server authentication being clunky, but my point is that SSH is doing client authentication better than HTTPS, which is orthogonal to it doing server authentication worse.

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.

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

The usual way HTTPS client auth works is to issue some sort of persistent access token that then ends up sitting on the filesystem without any sort of additional protection, or alternatively to just fall back to username and password without any kind of MFA. It's somehow even worse than the SSH situation. The use of x509 client certs would be a huge improvement here, but I don't know of any git hosting services that support that.

Corporate networks will happily do DPI on TLS, no so much with SSH. So this 'error' of GitHub might be intentional in order to mold everything into something which they can monitor.