Anything is better than a 30 character password, including quitting computing and just doing vegetable farming on a tiny island, completely off every grid.

BTW, that remark I made about known_hosts applies to keys. You could put your SSH client keys (I mean private ones) on some HTTPS URL, so that you could fetch them to a brand new machine (e.g. burner phone purchased abroad).

And that's back to passwords: anyone else knowing that URL could fetch those keys, and their security depends on their password phrase. So we are back to relying on the strength of a password phrase as well as faith in attackers not knowing anything about such an URL.

Oh right; the URL could be .htpasswd protected too, let's not forget. :)

Re: hosting your key, I think that's quite reasonable, again, assuming your access control + encryption is good. It's a solid break-glass solution. I would add monitoring that alerts if it is ever used, though. Then you can remediate quickly on the off-chance it is compromised. In day-to-day use I would stick with a different key that only lives on my machine.

> assuming your access control + encryption is good

Accessing a password-protected page over https is pretty much exactly the same access control + encryption as using a password with SSH.

That's access control and transport encryption. By encryption I meant the encryption of the private key itself. I would not upload a plaintext private key, especially for privileged account access, even to a server I control.