5

I know the real answer to the auditor.

We are a smaller company under 40 total employees that is also PCI level 1 compliant. We've always used ssh keys on internal servers. You can't ssh in from the outside and have 2 factor auth on the vpn. Our auditor has always been ok with us using ssh keys since he said we are a small company. Since the 2012 audit we've doubled in size and now he wants us to use passwords to ssh in via something like LDAP.

As a sys admin I hate having to ssh in and enter a password all the time. Is there anything I can go back and tell him that using ssh keys is just as secure?

AviD
  • 72,138
  • 22
  • 136
  • 218
Mike
  • 165
  • 1
  • 5
  • > I know the real answer to the auditor. I'm not sure what you mean by this. Which PCI requirement (need a number) is the auditing trying to meet here? And what risk is the risk the auditor is trying to mitigate? I agree that having to enter a password is a hassle. I consider ssh pubkey auth plus a password for the encrypted private key to be 2fa and better than having just a password. Is he wanting you to require key auth *and* password auth via LDAP on your internal servers? – Tracy Reed Dec 18 '13 at 01:11

3 Answers3

5

SSH keys are OK regardless on your company size.

Let's get deeper in the PCI DSS (extracted from the version 3.0, but also in 2.0) :

8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users:
*Something you know, such as a password or passphrase
*Something you have, such as a token device or smart card
*Something you are, such as a biometric.

"at least" : one of the 3 options above is OK.

Official guidance about "something you have" :

 Note that a digital certificate is a valid option for “something you have” as long as it is unique for a particular user.

Conclusion :

SSH keys are compliant as long as each SysAdmin have its own keys pair.

In must add that best practices (and so PCI DSS req 2) will require to protect private key with a strong passphrase.

tripleee
  • 222
  • 3
  • 10
PCI Initiative
  • 96
  • 1
  • What scares me is that SSH with passwords is compliant at all; the possibility of using poor passwords is much greater than that of using a poorly-chosen random RSA key. – mikebabcock Feb 12 '15 at 17:55
3

I always had a problem with SSH keys when I was a QSA. Mainly because people basically build them once and then ignore them.

As a penetration tester there are many ways to gain access to systems. The easiest to me was always to gain access to a system admin system with ssh keys, or use a browser or other local exploit (phishing attack) to extract the keys & email or web/submit them out if I couldn't gain access directly to the system. Or just buy old hardware their it staff is selling with annual upgrades; I'm sure they aren't wiped and one of them has a key left on it. There are lots of ways to get access to the keys.

Once I had the ssh keys I then had access to everything. The best accounts to find were admins who were no longer with the company. With no central management then those accounts were most likely still in the system.

Ask yourself this. What are you doing to manage the ssh keys and accounts on systems? If you have local system accounts with local sudo and using ssh keys to access, what do you do when someone changes roles in the company or you hire a new person or someone leaves. Or worse, when you have someone malicious who knows they are leaving who pre-builds accounts and ssh keys before they leave. How do you monitor and control for that?

SSH keys usually leave your systems as dozens or hundreds or however many you have of individual systems.

Yes passwords are a pain, but many admins these days; especially those who are trained and given the right tools build strong passwords.

Also, with ssh keys, even with a passphrase; how are you controlling that? There is no way to centrally enforce passphrase changing, or even a strong passphrase. I've seen lots of ssh key passphrases with the password as "a" or "password"...

If you really want security you should look at a radius based token solution; but either way you should look at having your accounts centrally managed and controlled. winbind or even just ldap can be used for user account verification as well as proper user group authorization so you can properly control access to systems.

It's not an easy answer; but the question you need to ask is are you wanting this for convenience or security?

David M. Zendzian
  • 31
  • 1
  • 1
    This response makes no sense. How do you get your hands on keys in the first place? Any answer leads to you getting the password too if they had one. Note: no password is as long and complex as a key, so it inherently less secure. Yes, key management is important, but disabling keys is very easy. – mikebabcock Jul 06 '16 at 19:55
2

Since your shop has doubled in headcount this increases the risk that someone will unintentionally or intentionally mismanage one or more SSH keys. Using SSH keys without going through LDAP creates the vulnerability that someone can, for example, make a connection to the system account and pull all the cardholder data out of your database, all as an authorized user and subverting auditing / access management.

See 2.3, 3.6, 8.1.

Also see https://serverfault.com/questions/471753/what-are-best-practices-for-managing-ssh-keys-in-a-team

and

Best Practice: “One per-user ssh key” or “multiple per-host ssh keys”

Community
  • 1
user35648
  • 905
  • 6
  • 8
  • 1
    This answer should be expanded. SSH keys are still a valid form of authentication as long as key management is being enforced. It's best practices to put two factor and/or secrets vaults in for admin accounts. – Shane Andrie Sep 27 '17 at 15:00