I have disabled PAM by default on all my boxes that run sshd for the last 9 years out of habit, I long ago forgot the reason why (probably because the gentoo sshd handbook entry said it was a good idea). Why UsePAM is set to yes in sshd_config by default on many distros is beyond me.
Because PAM is the default authentication framework on all those distros. Yes, it's a disaster of complexity and something pretty much no one understands. But it's what we have. Maybe a rearchitected replacement will land in systemd someday...
The OpenSSH Bug That Wasn't
91–92 of 92 posts
Re: The OpenSSH Bug That Wasn't
#92Earlier quoted context omitted.
Your security recommendation is bad. > password manager on an encrypted thumbdrive, along with your gpg key and private ssh key with the decryption password + password manager password being the only ones you remember You have to give the system both passwords to use the thumb drive, except that these passwords, rather than being compartmentalized as currently is the practice, can steal literally every key I need to…
I appreciate the detail in your criticism and largely agree with it excepting that I value usability. I'll at least hold that my recommendation is significantly better than the "state of the art" for a person who talks about ssh password auth -- typical state of the art there is using the same short memorable password for every server. You're, of course, right that it's even better to have a second factor for each en…
To use something that's more in the middle: you'd want to use a password manager per client (for sure) and probably divide low-security and high-security credentials.
It's just that the remote SSH servers at my job are fundamentally an expediency meant for emergency situations, and often can only be used once without being reset, eg, locking the account after a single session and requiring someone from inside the network to unlock it (after setting a new, one-time password).
In this sense, their security is primarily that I must compartmentalize each emergency server, and only use it during the appropriate emergency. However, during emergencies, the nature of the emergencies overrides the risk of compromise when accessing those commands, which typically are just specific scripts run from a locked down account.
Thus the security of the system depends on my ability to keep emergency credentials compartmentalized when using a different set, so that way only a single set of emergency commands are available to an attacker at a time -- and only when they're commands related to an already failed system.
Thus the security of the system is best preserved by strategies which highly compartmentalize the credentials, since they're meant to be used on potentially unsafe systems only during emergencies.
I guess I just remember 3-4 passwords like it's my job to -- because it is.