> First, some vendors make it difficult to associate an SSH key with a user. Then, many vendors do not support certificate-based authentication, making it difficult to scale. Finally, interactions between public-key authentication and finer-grained authorization methods like TACACS+ and Radius are still uncharted territory
Keys (with/without certs) are the best route, but not always possible for every situation.
Honest question, unless it's mandated by your employer, or you don't personally care, why would you ever choose to use a service that doesn't offer that?
There are not many network vendors. Check the link in the first footnote for an example how Cisco, the leader in the field, makes it difficult to deploy SSH keys. This is getting better. For example, Juniper (another network vendor) now supports SSH certificates.
I have no idea what's going on in the footnote, but deploying SSH keys on Cisco equipment is like 3 commands (conf t, user x, ssh something something) to deploy public keys, not hard at all.
It's been a few years, but this requires manually deploying keys and adding/removing users on all your devices. Most use TACACS+ and/or Radius to centrally manage users, which don't support keys in that way (or at least didn't the last time I worked with them.)
Another possibility would be to use CA certificates for authentication and only TACACS+ for authorization and accounting. Juniper now supports CA certificates. Cisco may in 10 years.
Public key authentication is actually a Must Implement for SSHv2. Since SSHv1 is long obsolete, any gear that doesn't have pubkey doesn't actually have a de jure SSH implementation.
That doesn't mean it's always easy to install and manage keys. For example, the author of the passh tool recommended by this post somehow managed to come away with the impression that OpenWRT's ssh server only supports password authentication.
Another example: Ubiquiti gateway consoles like the UDM-Pro. You can install an SSH key but these are erased on reboot. So after every reboot I have a script that uses the SSH user password to re-install an SSH key but this can’t be relied upon and I haven’t found a way to make an SSH key persist.
One good example is bringing up equipment that comes out-the-box with a default password. This is common on BMCs for example, and you have to initially provision things somehow.
Bad(ancient) design, can you honestly say you look at that little image it generates and verify it is correct? Or actually read the acceptance of the key? No one reads that stuff or checks it, they just press yes to get to what they want to do.
