4

I am looking for a way to share admin privileges on some hosts without providing the admin password. From his link, I was thinking of using a primary host from which every user can sudo -u user to have access to the specific SSH key and connect to the other computers without any password. The SSH keys have strong passphrases and are loaded in the memory by an admin.

If userA needs root access to lan1 computers, we just add him to the sudoers file as : userA ALL= /bin/su - lan1 where lan1 is another user containing an SSH key accepted by all hosts on lan1. Then, userA can have access to the specific SSH key at user lan1 and do sudo su - lan1 ssh root@[computer_in_lan1] without knowing any root password.

Problem is that I need to enable root SSH login for lan1 and this is a bad thing. I am wondering : root login would require an SSH key so guessing anything would be impossible, what is the risk except tons of bots logs ?

Now, are there any solutions for sharing a root access without having to share the password ?

Improve this question
5
  • 1
    Any chance that you are willing to use a network based solution like LDAP?
    – M'vy
    Mar 9, 2015 at 15:37
  • Actually, I do not need a particular way to manage users and passwords since they are very few. However, I would like to get the best way to do this - meaning I would like something easy to deploy with a few tools I can use.
    – Bamse
    Mar 9, 2015 at 15:46
  • I would avoid LDAP for now. My problem is not a priority at all, rather more a simple question of interest.
    – Bamse
    Mar 9, 2015 at 15:48
  • 1
    It would be simplest to have non-privileged accounts for all administrators on each system, then require them to use sudo to elevate their privileges once they're on the system. Is there a reason you're trying to avoid that?
    – gowenfawr
    Mar 9, 2015 at 16:03
  • For every user, I would need to set up their accounts on each machines they need when with this solution, each machine is accessible via one host, following the user's right to sudo su - lan1,2,3... ssh root@lan1,2,3 I agree it is not a big difference now for me but with a lot of users, with some who need specific accesses at different levels and others not, some new users coming in the company and others leaving, having just one host to manage them is simpler.
    – Bamse
    Mar 9, 2015 at 16:30

2 Answers 2

Reset to default
2

Short version:

  1. Your solution sacrifices logging and auditing accountability, just so as you're aware.

  2. If direct root login is a problem, use a generic non-admin user to ssh in and then sudo to root.

  3. If you want to be clever, configure sudo (via pam) to prompt for a human-specific username and password so that local privilege escalation is tied to the responsible human.

Long version:

Direct root login is bad for two reasons:

  • It lowers the barrier for an attacker to get in as root.
  • It removes the audit logging that ties system changes back to a responsible individual.
  • Auditors jump all over it like weasels in bacon.

If you were to replace the ssh root@[computer_in_lan1] with a non-privileged user, e.g., ssh myadmin@[computer_in_lan1] and then require the user to use sudo to gain root privileges, then you will address the first reason. However, the second is still a problem, because if multiple humans can log into myadmin, then who is to know which human did so?

One way to compensate would be to require per-human authentication once local to the system. Once the user logs in as myadmin, then they will run sudo su - to gain root privileges. A clever solution would be to require individual authentication from humans at this point so that you can tie the act of gaining root privileges back to an individual.

Like most things, sudo uses pam as it's authentication backend. And pam can be configured to prompt for a username and to go out over the network with something like LDAP or RADIUS. So, Joe logs in as myadmin via ssh and types sudo su -; he'll have to enter username 'joe' and his own password to get root. When Kate logs in with the same generic myadmin account and types sudo su -, she'll need to give username 'kate' and her own password to get root.

Now, setting that up would be as much, or more, work compared to setting up individual user account across all the systems. The maintenance might be less. But it would be a hell of a lot more fun to do.

Improve this answer
5
  • As long as the central "sudo" server does audit accesses to indivual names, you know who did what. For example if a user sudo from the central server to lan1, then the central server might logged: 2015-03-10 01:00 Someuser1 sudo lan1. Lan1 logs "2015-03-10 01:00 root did something". Then you can correlate things by the time and dates.
    – sebastian nielsen
    Mar 10, 2015 at 4:11
  • That solves the problem nicely and as you said, it is way more interesting to do ! Thanks.
    – Bamse
    Mar 10, 2015 at 8:53
  • @sebastiannielsen, correlation in that case is not direct. If two admins are logged in concurrently, it can be difficult or even impossible to map actions on the target system against the ultimate source on the central system. Once you move the authentication locally, the mapping of pid to log entry usually provides a direct correlation. I know which I'd rather be dealing with during an audit or an incident :)
    – gowenfawr
    Mar 10, 2015 at 11:05
  • @gowenfawr I would say, easy to prevent. Disable concurrent access, so only 1 login to a root account on a host at the same time is permitted. You could even let the indivual hosts syslog to the central sudo server, which replaces "root" name with the user that is currently "authenticated" to the host in question. So if SomeUser1 is autheticated to lan1 as root, and concurrent access is disabled, then lan1 syslog "root does that" to sudo server, then sudo server replaces "root" with "SomeUser1". About the OP's issue:
    – sebastian nielsen
    Mar 10, 2015 at 22:00
  • I guess the OP is managing a large amount of identical accounts on a large amount of hosts. Lets say if 50 different sysadmins should have identical access to 50 different hosts. Instead of managing 50 user lists of 50 users each, its then a lot easier to have that user list ONCE on the sudo server, and then let the sudo server authenticate using a shared account on all hosts. Then you also avoid irregularies between the user lists, for example one host might not know that Employee01 is terminated. Imagine then the headache of syncing password Changes between all hosts.
    – sebastian nielsen
    Mar 10, 2015 at 22:02
2

I recommend that you do not permit direct login as root via ssh on any system. As mentioned in gowenfawr's comment above, it is better to have personal accounts for everyone who will be administering the system on all of the nodes, and give them access to sudo to root locally. They would not need a root password on any node for this; they would use their own password or other credentials.

This can be automated with distributed authentication tools such as LDAP and RADIUS, or with a client-server tool in which the client runs locally on each node, gathers the information from a central authorization system, and creates and maintains the individual user accounts on the systems.

Failing that, you may want to set up a dedicated (non-individual) account on each node whose purpose is to run a specific set of commands as root via sudo control, and have a means for the public keys of all the administrators on the central "jump server" distributed to the authorized_keys for this account on all nodes.

The key (pun intended) is to protect against misuse or interception of the private keys of the administrators on the central node by not allowing unrestricted access to the root account remotely, and instead relying on local privilege escalation (sudo).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .