Can anyone tell me why we do not have a mechanism like SSH keys to authenticate to websites? Genuinely curious.
One option is each site you authenticate to needs to issue you a certificate for your identity on that site. Web browsers would presumably become responsible for minting the CSR during registration, and then hanging on to however many private keys and certificates (dozens? hundreds? thousands?) the former of which would be very vulnerable to malware.
The other option is you get one certificate from some acceptable trusted CA, or maybe you just mint your own, and then use that everywhere. This destroys privacy since trackers can just correlate the presented certificate.
There are also a whole bunch of environments where the secure web appears to work, but mutual authentication (the use of client certificates) does not work. In these environments the owner of the computers (which may not be the user) has authorised a middlebox HTTPS proxy. You can't do this with mutual authentication, you can find companies that are sure they have a solution, unless payment is conditional on the solution working rather than just being promised - at which point they'll remember they can't do it.
The reason this can't work is that TLS allows both parties to detect who they're talking to with mutual authentication, whereas in the usual single auth case only the client knows there is a middlebox. So to work around this you'd be reconfiguring Google's servers (as an example), not your computers, and unsurprisingly Google does not want that.
There is a third option: You keep a single master secret in the browser, and combine that with the identity of the site (e.g. the domain name) via a secure trapdoor function to create a unique per-site key pair which is then used for public-key authentication with only that site. The site-specific secret is easily recreated from the master, but without the master secret there is no feasible way to correlate two site-specific identities.
This is the approach used by modern (Hierarchical Deterministic) Bitcoin wallets. Older versions used distinct random private keys for every transaction, which as you say made key management rather painful. A single key which can be backed up once and used for any number of separate authentication channels is far more ergonomic.
Middleboxes are indeed a major problem for TLS mutual authentication. IMHO this would be a good reason to favor TLS client certificates for popular web sites—perhaps we could finally get enough pressure to see these MitM-boxes booted off the network.
In summary, while browser and mobile OS vendors could cooperate to improve the situation with client certificates, as of now, there appears to be no interest from any party to do so, and unless it happens, it is not worth it to use client certificates at all.
The obvious solution, rather than syncing the certificates, would be to allow more than one client certificate per account. Each device would have its own certificate. If one device is compromised you need only revoke that particular certificate; other devices could still access the account.
To avoid the need to manually register multiple certificates for each account you could cross-sign the per-device certificates; i.e. if key A is registered, and key B is signed by key A, then key B can also be used to sign in, perhaps with a warning sent to the owner of the account about a login from a new device.
Most of the current web browsers support it AFAICT:
* https://caniuse.com/#search=webauthn
The upcoming Safari 14 will add further support:
* https://www.theverge.com/2020/6/24/21301509/apple-safari-14-...