>By forcing users to select secure passwords you will prevent users with accounts on your servers from using passwords like "password".
or you know, disable password login and use ssh keys.
or you know, disable password login and use ssh keys.
For SSH, yes, keys should always be used and the guide covers disabling password and root SSH logins. Here's section 4.5:
> Remote access is always through SSH on Linux servers. In most cases, SSH is setup to allow access to user accounts via passwords. By allowing users to log in to your server using their passwords, you allow hackers to brute force attack your server from anywhere in the world. Instead, your servers should use RSA keys to allow users to login. This will only allow users to access the server from the computer that contains their private key. Since private keys will be password locked and never shared, this will ensure that only authorized users will be able to access the server.
Check out section 4.4 for a detailed overview of Cracklib.
Adding a passphrase to your SSH private key is a best practice but not easily enforced without some manual process or command and control for sysadmin workstations.
Hardware tokens containing private keys and used via PKCS#11 are another option for providing some assurance. The token itself can require a PIN.
If you select an easy passphrase for your key, it's similar to selecting a weak password for your bank account when your bank doesn't enforce password constraints. Buyer beware.
An ideal solution would be a two-factor key encryption. That would require the two-factor key to unlock the private key. There might be something out there like that. I haven't looked though.
unfortunately that's true. But it shouldn't have to be. There is a libpam-ssh-agent-auth which makes use of a forwarded ssh-agent socket to authenticate to whenever sudo needs it, which means that you have to re-authenticate your ssh-key locally.
It works, but it never really took of, and tbh I wouldn't trust it's security. But the authentication flow is something I would want.
But you're correct, an attacker on the remote system with access to the socket (i.e. usually root) can steal your identity.