20

Possible Duplicate:
What’s the common pragmatic strategy for managing key pairs?

I was part to a conversation last week about which approach to ssh keys is more “secure”. Note, that when contemplating “secure” we were trying to factor in human behavior (the most insecure part of any security system).

The ssh environment is primarily Unix/Linux machines (some PuTTY too). U sers of ssh are “human users” as well as “automation accounts” that are used to execute scheduled tasks/scripts that require scp/ssh to copy files or execute remote commands.

In attempt to come up with a best practice for our users, we are contemplating the following recommendations:

“one ssh key per-user” - The user generates a single key pair and submits the public key to our automated process which copies the public key to the user's authorized_keys file on hosts where the user is allowed to login. The user is instructed to use the same pass-phrase protected private key on all hosts that they use as an ssh client. This approach results in one key-pair for each user.

“multiple 'per-client-host' ssh keys” - Users should generate a ssh key pair for each SSH client. The user submits the public key to an automated process which copies the key to authorized_keys file authorized_keys file on hosts where the user is allowed to login. This approach results in “u x c” key pairs; where “u” is the number of users and “c” is the number of clients.

In our discussions we've noticed advantages/disadvantage for each approach. For example: the “one ssh key per-user” approach has the advantage of impressing on the mind of the user the importance of their only key as well as the ability for us to audit the presence of the user's one public in audits of authorized_key files. On the other hand, the “multiple 'per-client-host' ssh keys” approach has the advantage of allowing audits of authorized_key files to determine the user and the client machine that is able login – which seems particularly useful for understanding types of access that non-human accounts (run scripts which call SSH/SCP) have.

I'd be very interested in hearing what has worked well for people on this forum. Thanks in advance.

Community
  • 1
Srinivas
  • 201
  • 1
  • 2
  • 4
  • This is the *inverse* scenario of the question it is marked as a duplicate of (using the same key to access multiple hosts). This is asking about using multiple keys to access the *same* host. – david25272 Oct 07 '16 at 05:03
  • Why not both? If you can support multiple users submitting one public key for you to upload to a list of hosts, you can support some of those users submitting multiple public keys for zero additional cost. So allow people to do either, presenting the easier and more user-friendly option front-and-center in tutorials or explanations, while leaving the door open (or even explicitly mention support as a footnote or afterthought) for users to practice multiple-keys-per-ssh-client workflows if they value the extra security. – mtraceur Jun 05 '18 at 04:47

2 Answers2

15

I recommend you adopt the "one ssh key per user" model. It is easy to use for end users, simple to explain to users, and is likely to meet the security requirements.

Ease of use is very important. If a security mechanism is too hard to use, people will find a way to bypass your security mechanism. An easy-to-use, pretty good security mechanism is far better than a hard-to-use security mechanism that is in theory highly secure (because in practice, if is hard to use, it probably won't be as secure as you expect once people find a way to bypass the security mechanism so they can get their work done).

I think "one ssh key for client machine, per user" is a bad idea. It sounds like a mess. Frankly, it sounds like IT run amok, in the sort of way that gives security a bad name and makes people hate IT departments. You mean I have to generate a separate SSH key for each client, and manage them all? All for an amorphous security benefit that isn't clear? Ugh! I would hate to be in charge of selling this to users.

I suggest that think of these kinds of decisions in terms of "compliance budget". Your employees will put up with a certain amount of annoying compliance mandates (e.g., security requirements) imposed upon them. Up to a point, they'll follow these mandates. However, if it gets to be too much, eventually they'll get annoyed and just do whatever they have to do to get their work done, even if it violates all security principles. Therefore, imposing too many requirements or too much inconvenience can be counter-productive to security. So, before imposing any kind of security requirement or security-related inconvenience on users, think very carefully. Imagine that you have a very limited budget for imposing mandates. Is this the best item to spend your limited "compliance budget" on?

On a related note, I think the benefits of "one ssh key for client machine, per user" are pretty minor. I don't understand why anyone should care all that much what accounts I can log into with my laptop, vs my desktop. Is this just micromanagement? Who cares? It's me, either way. If you trust me, you trust me, no matter which of my machines I'm using, right? It's not clear to me that this is such a big deal that you'd make your users lives harder because of it.

P.S. You mention something about managing what privileges non-humans have. I didn't quite follow what that was referring to. You mentioned scripts that call SSH/SCP, but who is invoking those scripts? If it's a person, then presumably that person is authorizing the activity, right? If it's not invoked by a person, then I'm not clear on how that would even work (in my experience, such scripts don't have access to your SSH private key, since they don't know your passphrase and aren't attached to any ssh-agent session that would let them access your SSH private key). I don't know if I'm missing something important in that statement.

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • Basically, what we have are cron jobs which need to invoke remote commands (via SSH) and SCP files. These cron jobs are owned by a accounts not associated with a human. For example, an account called "autodrop" runs a cron job which SCPs files into a directory and invokes a command on the remote host to process the files. For this discussion, it's not important exactly what "autodrop" accomplishes by doing this -- only that "autodrop" runs unattended. There's no human sitting behind a console to type in a passphrase (autodrop's private key is not encrypted). – Srinivas Sep 05 '12 at 19:44
  • @Srinivas, got it, makes sense, thanks for the explanation! Well, the question of what to do with "automation accounts" might be a bit different from what to do with "human users" (I dunno; I haven't thought carefully about the issues with "automation accounts"). My answer above is focused on the question of "human users", and I don't know if the same arguments apply to "automation accounts" or not. Sorry to be unable to offer any advice on that one; if you have remaining questions about "automation accounts", you might want to open a separate question on just that topic. – D.W. Sep 06 '12 at 05:47
3

I have a hard time thinking that the user experience on the many-to-many approach will be acceptable. The confusion surrounding trying to remember which pub/priv key pair goes with what system seems overly cumbersome.

The spirit of the one-to-many key approach seems best in terms of the management and user experience aspects. I say the spirit because I think that if you have more than a very small number of users and systems, the management piece will become difficult quickly. You're heading towards a centralized access management solution, so why not go all the way? Setup an LDAP server (AD/OpenLDAP/this thread has some ideas), define roles for your users, give those roles access to the servers/systems they need, and assign roles to users as they need them. This lets you provision/deprovision access to many systems with a simple role change and keep all audit logs in a central location.

It's a great question that deserves some serious pondering about the scalability and practicality of a solution as your organization grows in numbers and complexity.

Community
  • 1
bobmagoo
  • 434
  • 4
  • 11