-1

I have Linux a server where I would like to add few other people besides me as a root users. All the users need to access this server very seldom if ever. As a first step I set a root user a password which we all know. Then I added those users with useradd:

useradd -ou 0 -g 0 user1 -d /root/user1/ -s /bin/bash
useradd -ou 0 -g 0 user2 -d /root/user2/ -s /bin/bash

After that I copied a password hash of a root user to user1 and user2 in /etc/shadow. Then I created .ssh/authorized_keys file for each user(both user1 and user2 have their personal SSH public key there) into their home directory and finally configured PermitRootLogin without-password in sshd_config. There is no authorized_keys file for root user, i.e. it's not possible to log into server using user root.

This is basically what I need, but maybe this setup has some (security) drawbacks and there is a better solution?

  • 1
    Why do you want these accounts to be like a root account? If you share the password why don't they simply log in as root? (Not that I'd recommend that but if you understand and accept the consequences that is just the least complicated solution). Using sudo as @I_GNu_it_all_along suggested is in my opinion much better. – Bram Aug 19 '16 at 15:52
  • 1
    There's no need for the users to have the same password. Though if you never intend to use the passwords, you could just put an invalid hash for the users, preventing using the password even in theory. – ilkkachu Aug 19 '16 at 16:10
  • @Bram In those very rare cases, when others log into this server, they need to perform actions(related to network configuration and qemu VMs) in root user rights. On the other hand, it seemed like a better approach to me if each login user still has its own home directory under /root and username root is not able to log in over SSH. @ilkkachu Did you mean to put an invalid hash for all the users who log into server over SSH in root rights and only user, who has a valid hash, is a root user in order to allow local login if needed? – Martin Aug 23 '16 at 7:56
  • 1
    @martin: network configuration and qemu config can be done just fine using sudo. No reason at all for these user's UID to be 0. And no reason to share/sync passwords. But do note that at least in the default configuration these users then need valid passwords. – Bram Aug 23 '16 at 18:49
  • @Bram I'm aware that network and qemu configuration can be done using sudo. However, based on the discussion under my initial question and answer by @I_GNU_it_all_along, it looks like my setup(with suggestion from @ilkkachu about invalid or blank password hashes for all the users other than username root) has no (security) drawbacks compared to sudo setup. However, I do agree that sudo setup is more conventional approach. At least on modern systems where sudo is available. – Martin Aug 24 '16 at 7:16
5
+100

What you have done is atypical and so I would not recommended it. Most programs assume a one to one mapping between uid and username. You could potentially open yourself to weird bugs/unknown behaviour or worst security vulnerabilities - This is an unknown for me so I cannot recommend it when there are better/more typical ways to achieve your goals. Given this, the first thing I would do is delete the accounts you have created.

Now, if the users require root access there is nothing majorly wrong with giving them access to the root account, assuming you/they understand the risks associated with the root account. From a security perspective the weakest point in ssh is password auth, so I highly recommend disabling that. This can be done by editing/adding the following to /etc/ssh/sshd_config

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

However, there are some issues with having root privileges for longer than you require. Most notably that it is easier for a simple mistake to do more damage. Given this it is better to create some unprivileged accounts that the users can login to. Once logged into their user that can obtain root privileges when required by using su - and the root password.

Now, remote attacks are generally against the root users (as well as common users names such as admin), with password auth disabled you generally do not have to worry about this as key auth is strong enough. If you have user accounts that can obtain root privileges (as described above and below) then you can further increase security by disabling the root account entirely by add/editing the following to /etc/ssh/sshd_config.

PermitRootLogin no

WARNING: Ensure you have a user account that can gain root privileges or you can lock yourself out of the server.

This might help protect you against misconfiguration or possible future vulnerabilities against ssh/openssl as the attacker now also requires a username to gain access to an unprivileged account where they then require a password to gain full root access.

Finally, it is not best practice to share password around multiple users. If you wish to revoke someone access for any reason everyone needs to learn a new password. It is better to obtain root privileges using the user's own password. This way you simply need to lock the user's account, change the root password (as they could have modified it given they have root privileges) and everyone can continue to use their own passwords without issue (note there are more issues with locking someone out of a server they have had root access to as they could have done anything to the system, including changing other users passwords or adding their key to other users).

To do that you can use sudo in place of su to allow the users to obtain root privileges with their own password as aspose to roots. To do this install sudo and add the user to the wheel or sudo group (depends on the distro you use). Users can then use sudo <command> to run a command with root privileges or sudo -i to gain a root shell.

This also gives you better auditing logs as each action executed by sudo is logged against a username - assuming you do not simply sudo -i all the time.

You can even take this further by restricting users to running only a subset of commands rather than giving them access to everything. This makes it easier to revoke access in the future as they are able to do less to the system. But this depends on how much you trust your users and can be annoying if you do not know everything they require access to.

Given this an attacker requires a username as well as an ssh key or a vulnerability in key based auth to gain access to the server, where they can do limited damage. Then they require a password to actually gain root privileges and do real damage.

Security is applied in layers, the more layers you have generally the more secure you are. But added layers also decrease usability. It is up to you to decided the balance you wish to apply to a given system. The steps I have described above will add allot of security at a minimal cost to usability. There are further steps you can take to lock down systems even more than this but for most cases this should be enough.

4

Don't do this! I can think of no good reason to have a non-root user running with root privileges as standard. That's dangerous yo.

Instead, just add the users to the sudo or wheel group depending on the distro (usually sudo).

This can be done with useradd -G sudo -s /bin/bash <username>.

As for SSH authentication, doing so with their keys will be totally fine.

  • 1
    Perhaps add a note about the added benefits that users can (need to) use their own passwords for sudo so the root password does not need to be shared and that commands executed via sudo are logged so you can find out who did what. Users also have their own shell history instead of mixing up the root's shell history etc. – Bram Aug 19 '16 at 15:55
  • 1
    @Bram, individual passwords and individual homes you also get with multiple uid 0 users. And if anyone does sudo -s because they have more work to do than a single command, you won't get logging. Neither can sudo log how configuration files were edited etc., so the logging isn't that convincing an argument either. – ilkkachu Aug 19 '16 at 16:01
  • 1
    Not to mention that superusers can edit regular logs at will. Multiple uid 0 users are also about the only way to have multiple admins with different regular passwords and different root passwords. That is, if you create regular accounts too, which wasn't the case here. – ilkkachu Aug 19 '16 at 16:12
  • I tend to agree with @ilkkachu that in this particular case, where added users are also (trusted) administrators and equally responsible for the system, using sudo does not give any real benefits. – Martin Aug 23 '16 at 8:56
  • 1
    @ikkachu, remote logging solves a lot of your issues with auditing and isn't that difficult to set up. And, while I'm not a proponent of the root-equivalent accounts described in the original post, I have seen it implemented and working well in at least one professional environment. The whole security stance of a machine is one of personal preference: if the described configuration is one you deem acceptable in your environment, then it can work for you. Just make sure you (and your management) are aware of the risks and advantages. – Thomas N Sep 2 '16 at 13:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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