Home / server / Questions / 755373
Accepted
user22a6db72d7249
Asked: 2016-02-11 11:07:07 +0800 CST

Is logging in as a shared user a bad habit?

  • 772

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.

ssh

5 Answers

  1. Best Answer

    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.

    • 42

  2. 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.

    • 7

  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.

    • 3

  4. 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.

    • 3

  5. 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.

    • 1