Who says you can't brute force a key? Granted, it takes longer and people tend to not "pick poor keys" as they do passwords, but still. An ssh key is not a silver bullet, either. And passwords do not have to be shared (though I've worked for many a company in which that was the default policy, sadly).

No, but the system didn't let me in until I'd also entered my PIN.
Security-wise, using only a badge/token is worse than relying on regular keys. At least with keys, you normally can't tell from just looking at it which lock it belongs to, while badges are regularly equipped with company logos or even serve as employee ID cards as well. Which is why every company I've ever worked for or with has used two-factor authentication; token and PIN.
But that's just wrong. Passwords are perfectly manageable with a password policy, which can be enforced and audited by various technical, easily available measures.
As rocket357 pointed out, all this is true for certificates as well, including the "shared secret" part. Actually, passwords should never be shared between users, and there's no reason why any authentication scheme would ever have to rely on shared passwords.

Passwords have a number of weaknesses. They can be of poor quality if the system allows it, and a user may deliberately or inadvertently reveal a password to an outsider. Passwords are strings that could possibly be intercepted when used ("sholder surfing") and nothing prevents a user from violating policy by writing a password on a piece of paper. A good password policy can mitigate all of these weaknesses, except the one where a user blatantly ignores policy.

Certificates have a number of weaknesses. The crypto can be of poor quality or use keys that are too short if the system allows it, and a user may deliberately or inadvertently make a certificate available to outsiders. Certificates are files that have to be stored somewhere, and nothing prevents a user from storing a certificate in an insecure manner. Also, unlike a physical key or an RFID badge, a certificate is easily copied and contains a publicly readable Subject Name, so having a certificate fall into the wrong hands is the equivalent of losing a key clearly labeled "this key will open a door at Company, Inc." Most of these weaknesses are inherent to the certificate itself, and cannot be mitigated by policy or technical measures.

Using certificates as the only means of identification is certainly better than using a poor password, but that's only because just about anything is better than a poor password. However, a good password, one that's both complex and doesn't have to be written down because the user is capable of remembering it, provides demonstrably better security than any other single-factor authentication scheme, including certificates.

Your assertion that an exposed password prompt somehow represents a fatal security flaw, is just wrong. Every single web based service on the Internet works that way, as do most other protocols (POP, IMAP, SMTP, SIP, RDP, ICA etc). Using certificates as a single-factor replacement for passwords does not in itself improve security in the slightest, it just replaces one weakness with another.

1 members found this post helpful.

Rfid badges are very easy to duplicate. It takes some equipment and you would have to get close to a valid badge/card, but definitely not what I would call secure.

I'm not sure I understand this.. In what way do certificates contain a public readable subject name?
Is this the username@host comment following the public key?

I would imagine you would need both a unhashed known_hosts file & the private key to actually know know & do anything with it.

A very good point.

crucial .. you must .. it will never offer ...

Some of the users might be in a different situation as you. What applies to you doesn't have to apply to someone else. A Linux desktop user differs from server admin. Even server admin in enterprise environment might use different security rules as home server admin.

And for vulnerability discussion - don't confuse dictionary attempts with application vulnerabilities. These are two different things. And the possibility of exploitation applies to all services not only SSH.

So, your recommendation might be required but not necessarily.

You do realize that PKI (certificates) are not any more secure than passwords right?

The password in a PKI is the private key. And for that key to be usable it has to be readable as the key. If you use a password to decrypt it... you are using a password.

Yes, it is one more step.

but still a password.

The difference between the two scenarios is that you must possess something (the certificate), in addition to any password or other secret that may be required to unlock it. If you want to gain access to the system, you must somehow gain possession of it and not be caught doing it. Then, you only continue to have access until the particular key that you possess remains valid. That particular key can be revoked without affecting any other authorized key.

If you can ever successfully get to a login: prompt, then you are only one lucky-guess away from success. You could be anyone, anywhere. You don't have to possess anything. The computer can't distinguish between you and anyone/everyone else who also can "say the magic word."

That's why no one gains access to any office-building anywhere by whispering into the ear of the guard. They can't get near the place unless they possess a unique badge, issued to them and only to them, that when swiped or tapped at a particular door, causes that door to open.

No - the password is on a system. Any replacement of that key is also accessible the same way.

And that is also true for the password. Second, any system that can be accessed using PKI is also vulnerable to having any certificates on it stolen. So each system is ALSO vulnerable.

Depends on how the login is done. Personally, I prefer the Kerberos way. It still is a password, but only used to get initial credentials - Yes, those credentials can be stolen (its been done) but they automatically have a limited life (in one place I worked, they were limited to 15 minutes, depending on the network location of the system making the request, but users were to use it, get their credential, and use those credentials for a connection to a system - for the rest of a session; and the credentials were useless if stolen). It minimizes the use of the original password.
Unless the card is stolen, and that includes getting replicated. It is still using a password, only now it is on a physical object more easily lost/stolen/replicated.

Even smart cards that require a PIN activation are vulnerable. The PIN is the password. A bit trickier when the card locks itself with failure - but most are still vulnerable to having the PIN captured (nearly NONE of the current smart cards require the PIN entry directly to the card - thus the PIN is vulnerable to keystroke capture - been there, done that during testing).

All you are doing is moving WHERE the password is. Not removing the password.

One of the best smart tokens I've seen was from SecurID. You enter the PIN directly to the token, which then displays a passcode based on a random number sequence. When you enter that passcode successfully, the passcode is disabled. (you have to wait a minute for the next one, and re-enter the PIN into the token again, to retrieve it). Even so, that one too has been cracked, much more difficult though - the validation is done at the server and it was necessary to hack the server to retrieve the token authorization record.

And the PIN becomes the password. Only used on one device. Where I worked, we used both a kerberos password AND the SecurID passcode before giving out even a 15 minute credential. To capture the PIN required visual access to the user as the PIN is entered (the shoulder surfing attack, which works for both the kerberos password AND the PIN).