35

I've worked in organizations where instead of creating a new Ubuntu user per person that wants to log into a machine, the sysadmins simply add the ssh key of each user to .ssh/authorized_keys, and everyone sshs to the machine as (e.g.) ubuntu@host or ec2-user@host. (Incidentally, I've also seen this practiced on shared Mac minis in a lab setting.) Is this accepted practice, or an anti-pattern?

The hosts in question are mainly used for testing, but there are also actions taken that typically require per-user configuration and are tracked as being done by a specific user, such as creating and pushing git commits, which are currently done using a generic git user.

user22a6db72d7249
  • 503
  • 1
  • 7
  • 12
  • 23
    While many people have trouble with poly-amorous relationships, others handle them just fine, so I don't think it's necessarily a "bad habit" to share a... oh, nevermind, you meant user **account**. – HopelessN00b Feb 11 '16 at 04:02
  • Awww, someone edited out the clickbait title.. :( – Burgi Feb 12 '16 at 11:00

5 Answers5

42

Yes it is a bad habit. It relies on the basic assumption that nobody malicious is (or will be) around and that nobody makes mistakes. Having a shared account makes it trivial for things to happen without accountability and without any limit - a user breaking something breaks it for everyone.

If the reason for this uid-sharing scheme is simply to reduce the administrative cost of creating new accounts and sharing configuration, then perhaps the administrators should invest some time in an automation system like Ansible, Chef, Puppet or Salt that makes stuff like creating user accounts on multiple machines extremely simple.

030
  • 5,731
  • 12
  • 61
  • 107
thkala
  • 1,210
  • 1
  • 13
  • 19
  • 4
    It's not even malice, and it's also not even incompetence. When *anything* I do doesn't work, I can't assume I would have remembered anything that has been done on this account. – djechlin Feb 10 '16 at 23:22
  • Principles of secure data: Integrity Confidentiality Availability Accountability. +1 for using the word accountability – DeveloperWeeks Feb 11 '16 at 15:24
7

To start with this doesn't shock me, and I work in an extremely secured environment. Everyone has his own user and machine and ssh key, and for working on a server we ssh in, as root or as another user, through a logging relay if necessary. Everything we do is logged as having been done by the owner of the ssh key, so accountability is OK.

What would the alternative be? Lots of things must be done as a certain user, not to mention root. Sudo? That's OK for certain very restricted tasks, but not for sysadminning the machine.

However I'm not sure about your last paragraph, do you mean that someone could push a git commit a a generic user? That would break accountability, and breaking accountability is bad. We do git from the machine where we are logged in and we authenticate to git with our ssh key...

Authentication, authorization, and accounting (AAA) is the classic expression: you are authenticated with your ssh key, you are authorized to do anything the generic user can do because your key is in the authorized_keys, and you need accounting so that what you do can be reviewed after the fact.

Law29
  • 3,507
  • 1
  • 15
  • 28
  • 3
    So the generic user has some kind of authentication (ssh key?) that is authorized to modify the git repo? That is really not good. Not only because it breaks accountability for that commit, but also because any person can copy that key and use it from somewhere else. When I have that kind of problem, I copy the code or the diff to my local machine and commit it from there. – Law29 Feb 10 '16 at 20:23
  • 2
    Why exactly isn't `sudo` acceptable for general administration of a machine? – Blacklight Shining Feb 11 '16 at 15:25
  • 4
    you ssh in as root in "an extremely secured environment" oO? – xaa Feb 11 '16 at 19:31
  • @BlacklightShining If you have to be able to do anything (chown, chmod arbitrary files, install servers, mount filesystems, there is nothing to be gained by sshing in as user and doing a sudo bash. Instead, ssh in using either a logging relay and/or log everything to a remote server with t.he owner of the ssh key that ssh'd in. – Law29 Feb 11 '16 at 20:00
  • 1
    @xaa Yes I do, and I fail to see a problem with that. Everything I type is logged to other machines. "Don't work as root" is a totally useless maxim when the machine is a server where everything you might possibly want to do needs you to be root. – Law29 Feb 11 '16 at 20:49
  • @Law29 The issue with sharing a user is that you don't get the accountability that you otherwise might; actions taken are logged as having been done by the shared user and there's no way to be sure who it really was. If you do accounting another way (and you do it _well_), then you've solved that problem. – Blacklight Shining Feb 11 '16 at 21:22
  • @BlacklightShining And if I log in as myself and do a sudo bash along with twenty other people, I won't have the accountability I need, so I prefer my way :) – Law29 Feb 11 '16 at 21:34
  • @Law29 note that having a generic git user _should not_ be a problem (on a proper system), as that's just the account under which the vcs is run. You are actually running a forced command (not a shell) that restricts you to running git and sets your user based on which ssh key was used. See eg. [gitolite](http://gitolite.com/). OTOH, I agree you shall not copy your personal ssh key to a shared account! – Ángel Feb 11 '16 at 21:39
  • @Ángel yes the git account itself is not a problem at all, the problem is not being able to identify the person responsible for a code change. – Law29 Feb 13 '16 at 21:30
3

It clearly depends on the use case of the system. If it is system for testing from time to time it is fine for me. We have also such systems. If the company does not have any kind of identity management (LDAP, IPA), then creating new user without any remote control on random system is quite burden.

But for every-day work when someones mistake makes whole company unable to operate is not a good idea.

Jakuje
  • 9,145
  • 2
  • 40
  • 44
  • Exactly, if you don't or can't have a directory service, creating and managing thousands of accounts is impractical. – Jim B Feb 11 '16 at 04:07
  • Even if you can't use LDAP you're still likely to have SSH-access (or Powershell on Windows). You're still gonna need a way to manage the authorized_keys file on your hosts for all those accounts (unless you're also sharing passwords) and a ton of other settings. I have to wonder why you're not using some kind of configuration management (e.g. Puppet, Chef, Ansible) If you have that many users or servers. Takes away that burden, and gives you process control, accountability and auditability in return. – Martijn Heemels Feb 11 '16 at 18:46
3

All those answers address the concern of accountability which is an important and real issue in itself, but using a shared account also allows for not-so-subtle attacks on other users:

Consider an attacker creating a malicious ssh script that logs the typed-in password and putting it in the PATH for that shared user (which is done easily). Now the next person that logs onto that machine with the shared user and decides to ssh to some other place (this time with his personal, unshared, account) may have a nasty surprise.

Basically, using a shared account on a computer is like drinking from the foot bath at the public swimming pool.

ereOn
  • 529
  • 1
  • 4
  • 15
1

In general, sharing one account is a bad idea for the following reasons:

  1. Every setting made for this user effects everyone logging in. (Promt, aliases, ...)
    1. You lose the possibility to find out who did what (accountability)
    2. One mistake in the configuration of the account ( for example accidentally deleting the ssh kay) affects everyone using that user account ( in that example lock out).

And fore sure there are even more downsides... But I don't want to get into it further.

The point is, it might be you are facing the need to share an account to manage a service that is executed under a certain user account where all admins should be able to access.

In such a setup you have the possibility to share this account to login ( for above reasions i would rather not do this) or you login individually and switch the user then to the shared account (I would suggest that).

Auditing tools would still allow you to track who has executed what but still sharing the same account.

Gerhard
  • 96
  • 5