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.
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.
Why not add libcrack (constraints) and auto-expiration of passwords instead of locking people out completely?
Also adding fail2ban is a very effective solution to prevent brute forcing.
> and for the love of god, stop leaving private SSH keys on servers
Why not? Unencrypted private keys are dangerious, OK, but I fail to see the problem with a good password protected private key?