They are correct. You can't enforce passphrases (at all) on ssh keys, nor can you enforce key rotation unless you have a system that issues both the public and private keys. Even then, the user can simply re-sign the key and remove the passphrase. SSH Keys used correctly can be more secure than 2FA, but I have yet to see anyone actually use them correctly. If you are honest with yourself, you know that most of the folks in your org don't have passphrases on their SSH keys. It is easy enough to test if you have something managing their laptops.

Ironically, things done for PCI/ISO27K compliance very often decrease security. Maybe not always, maybe not everywhere, but at least that's my experience with the companies I worked at and is also in line with the stories I heard about other companies.

Quite recently: Security was concerned about enforcing ssh key rotation and was pushing for sysops to generate and store (obviously - unencrypted) private keys for all users on a central jump host and provide users access to that host using passwords (for which enforcing lifecycle policies is easier).

I agree with that. Folks are forced to create little isolated environments that are less likely to be patched or monitored, for fear of bringing more systems into PCI scope.

That is slowly starting to change however. PCI DSS 3.0 gets a bit more specific and starts to go down some technical rabbit holes. PCI DSS 4.0 will be even more specific and have more technical requirements (vs. checkboxes)

That's an odd tradeoff. I'm going to have to disagree with the sibling noting that "compliance != security".

Here's the thing: they say they can't enforce users to encrypt passwords (hogwash; you can have a local agent that checks that), but do they check that users are providing good passwords? I have much more faith in a randomly generated key than I do in a human-generated password. The former pretty much requires compromising the machine; the latter I can just take pot-shots at the server with. (They do rate limit your SSH password attempts, right? right?)

Even if we assume that the password is good, and that the server won't allow infinite tries to guess it, the security is only equivalent: compromise of the user's local account will reveal the password (just sniff the password) or the key (just read the keyfile, and sniff the password if it is encrypted). I don't see any world in which a password is more secure than a key.

The parent comment is discussing encryption of the private key with a password, not passwords for connecting to the server.

The parent is discussing both, and I am too; specifically, the parent says,

> we're not allowed to use key auth.

i.e., they're using password based auth.¹ The point of my post is that while certainly users leaving the private key unencrypted isn't good, trading that for password auth leaves you in a worse state overall (IMO).

¹Of course, they could be using an auth scheme that is neither password nor key based. But given that the parent didn't come out and say that, my gut says that's not the case here.

You could require both pubkey + password:

https://sysconfig.org.uk/two-factor-authentication-with-ssh....

I believe this was attempted, but they were running an older version of openSSH that was only getting security patches. OTP was not being triggered if an SSH key was used. so it was either password + OTP or ssh-key alone. They opted to disable ssh-key auth as the solution

There's nothing in PCI which prevents the use of SSH keys. In no scenario is password auth more secure than key auth.

There is a step where the auditor will observe you entering a correct and an incorrect password to enter the systems. If your org is depending on SSH key passphrases for this step and you get the wrong person in front of the auditor (the one without the passphrase on their key) then you just failed the audit. The more steps you fail, the deeper down the rabbit holes they go with each step. If they see you are not failing, it will be a check-box exercise. Each auditor is a little different of course; but generally speaking, this is true.

What happens if an ssh agent is used? pageant requests the passphrase and then leaves it unlocked. Or is this audit step set up so I can remove the key from my agent and then demonstrate that I need a proper password to get in?

Compliance has very little to do with actual security unfortunately...

I've worked with an organisation with the following rules.

A user wants to write an SQL query. The user writes it in notepad or whatever, and saves it in a .sql file. The user then will right click on this file they just created, and hit "Scan with McAfee antivirus". If the .sql file they just created comes up clean, they can then open it in SQL Manager and execute it. If they want to then adjust the query, they have to close the file and start over, running the scan again. People can and have been fired over getting lazy about that process.

There's a security consultant with a clipboard who firmly believes this improves security.

I facepalmed so hard my forehead hurts