Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
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 at 4:02
Awww, someone edited out the clickbait title.. :( – Burgi Feb 12 at 11:00
up vote 42 down vote accepted

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.

share|improve this answer
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 at 23:22
Principles of secure data: Integrity Confidentiality Availability Accountability. +1 for using the word accountability – DeveloperWeeks Feb 11 at 15:24

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.

share|improve this answer
Yes, the last paragraph means that a user commits as a generic user. I agree that it breaks accountability. It's a convenience measure that if something can be fixed directly in the repo on the testing machine, it is fixed there and then pushed. That's the issue that prompted me to ask this question to begin with. – Jesse Sielaff Feb 10 at 19:50
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 at 20:23
Why exactly isn't sudo acceptable for general administration of a machine? – Blacklight Shining Feb 11 at 15:25
you ssh in as root in "an extremely secured environment" oO? – xaa Feb 11 at 19:31
@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 at 20:49

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.

share|improve this answer
Exactly, if you don't or can't have a directory service, creating and managing thousands of accounts is impractical. – Jim B Feb 11 at 4: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 at 18:46

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.

share|improve this answer

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.

share|improve this answer

protected by HopelessN00b Feb 25 at 3:36

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.