> millions of customer pubkeys is a pain And millions of passwords isn't because ... ? Whatever solution the industry has arrived at for storing a large number

> millions of customer pubkeys is a pain And millions of passwords isn't because ... ? Whatever solution the industry has arrived at for storing a large number of user passwords and authenticating against them, can be applied to SSH keys too. I would be greatly suprised if Github uses ~/.ssh/authorized_keys to handle SSH authentication at its scale. > Python/twisted and Go have decent SSH implementations but So is the case with HTTPS implementations. It's just a standard, how it's implemented is not under its control. On the other hand, we have some good implementations of HTTPS, and similarly we have good implementations of SSH too: libssh2. > Shells are scary. So don't use shells over the SSH protocol. Make the server execute (upon successful auth) something that isn't a shell. > Windows... Agreed. Until user-agents popularly support a protocol, adoption faces large obstacles. > HTTPS with basic auth headers is much easier to scale Easier how? You have to do less computation to verify the password? This has nothing to do with the transport, and everything to do with the cryptographic strength of the password. SSH is better here because of its good support of keys (versus TLS client certs).