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.

1
  • 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. Feb 11, 2016 at 4:02

5 Answers 5

41

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.

2
  • 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, 2016 at 23:22
  • Principles of secure data: Integrity Confidentiality Availability Accountability. +1 for using the word accountability Feb 11, 2016 at 15:24
6

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.

9
  • 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, 2016 at 20:23
  • 2
    Why exactly isn't sudo acceptable for general administration of a machine? Feb 11, 2016 at 15:25
  • 4
    you ssh in as root in "an extremely secured environment" oO?
    – xaa
    Feb 11, 2016 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, 2016 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, 2016 at 20:49
2

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.

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

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.

0

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.

You must log in to answer this question.