So maybe if you add constraints and force rotation you can eventually get a secure-enough system with passwords. You'll still be using a symmetric key rather than asymmetric, which means that compromises can be made worse (I get root on one server -> I get user passwords as they log in -> I have access to everything that they have access to now), and you've invested a lot of effort to secure it rather than just `PasswordAuthentication no`, `ChallengeResponseAuthentication no`, done.

Security is not a monolithic item with a single best practice. A horses for courses approach is better IMHO.

If you're exposing SSH to outer world, minimizing attack surface by removing users and/or passwords is good. OTOH, if you're not exposing these services outside, or putting them behind a VPN maybe with people connecting from unsecured locations, adding a password is always a good idea in my book.

A laptop maybe stolen, a workstation maybe breached if someone is not careful and losing a key create bigger consequence.

So maybe instead of a tug of war about which method is the silver bullet, we should discuss about which one is better, under which circumstances.

> Why not add libcrack (constraints)

If the user has a super secure password shared with a different, compromised service, libcrack will not detect that.

> and auto-expiration of passwords

Expiry results in passwords like: (prefix)Dec2020, (prefix)5, or cycling the last 2/3 entries. Keys can be relatively easily revoked and are guaranteed not guessable.

> If the user has a super secure password shared with a different, compromised service, libcrack will not detect that.

There's a module[0] for that (TM).

> Expiry results in passwords like: (prefix)Dec2020, (prefix)5

libcrack can enforce similarity and rotation checks too [1].

> or cycling the last 2/3 entries.

There's also another module[2] just for that.

> Keys can be relatively easily revoked and are guaranteed not guessable.

You're right but, a good password policy and infrastructure is not a simple straw man which can be set alight with a simple match. PAM can be a bit hard to understand but, once understood, it's pretty easy to create complex rules and flows.

If you get your workstation compromised somehow, you can always lose your keys. Then you need another password on top of your key to keep it encrypted.

At the end of the day, a good security policy is required. Keys, passwords, fingerprints and other identifiers are just tools. If you can design your defenses and moats well, you can secure your system with any method you want.

[0]: https://github.com/skx/pam_pwnd

[1]: http://www.linux-pam.org/Linux-PAM-html/sag-pam_cracklib.htm...

[2]: https://linux.die.net/man/8/pam_pwhistory

> libcrack can enforce similarity and rotation checks too [1].

How can it do that without the server storing plain text passwords?

Unless you're root, you enter your current password first for verification already?

Ah, ok, that makes a lot more sense. I was worried that the password history was stored somewhere.

> Unless you're root

I'm not sure I get this part, why does being root change things?

Normally PAM doesn’t ask for your current password during password changes if you’re root.

Also, root can change any user’s password without entering the current one.