Hacker News Reader

Comment by infotogivenm | Hacker News Reader

It’s covered under footnote #1:

> 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.

View on HN

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?

It may be a box configured and serviced by a vendor, and your org may be short on IT staff.

You may be in a position where you must employ and interact with networked equipment that does not support pubkey authentication.

Yeah this is why fido2 doesn't work either. Most embedded ssh implementations don't support it.

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.

"All implementations MUST support this method"

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.

Dell PowerConnect 5500 series has a very picular SSH implementation, which could be described as 'allow all SSH proxy for telnet'

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.

Here you go:

https://github.com/fire1ce/UDM-Persistent-SSH-Keys

That doesn't mean that a device that doesn't offer pub key storage is not accessible over SSH.

And if you don't, anyway? Do you not get to use the SSH(TM) logo on your product? You're reading MUST a bit too literally.

Exactly as I wrote, it means what you've got isn't a de jure SSH implementation.

Do with that whatever you will.

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.

Not on IOS XR: https://vincent.bernat.ch/en/blog/2020-syncing-ssh-keys-iosx.... The commands you mention are for NXOS.

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.)

There is an implementation with an extension: https://github.com/MarcJHuber/event-driven-servers/wiki/TACA.... But I don't know if there are any supported clients.

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.

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.

Reply on news.ycombinator.com