Ahem... Cisco supports SSH authentication using *X.509* certificates.
Unfortunately this is not compatible with OpenSSH (the dominant SSH
It's not a great solution, but it is certainly a solution.
The feature exists for some routers/switch models running certain licenses/images...
an existing 200 NE network is not likely to have the feature 100% available by accident, though.
On the other hand: the strategy of using local auth on devices and having a few local users
with specific privilege levels, and centralized systems that manage the ones creds for all
normal day-to-day usage: Storage and frequent automatic rotation of passwords, and
when an operator needs to login: the central system authorize a privileged User to access,
Either "check out" a device using AAA to decide who can check out which devices,
Or users run their SSH sessions through centralized connection managers
(Acting as a man-in-the-middle authenticating
to devices using its own credentials. Authorizing user commands proxied through
the server) - Allows AAA and command authorization to be performed by the central server.
My understanding is a good number of password manager products exists which will handle that,
and then the only AAA which network devices need to be concerned about for Authentication and
Authorization is Basic password auth, which all equipment supports. And the security problems
don't arise so much for using the TACACS+ / Tac_plus service Solely for Accounting
(in addition to basic remote syslog).
client implementation we use), which only supports *OpenSSH*
certificates.
--
-Jim