Is there a reliable way to make several user accounts behave as root, except sudo?

Question

I and a friend are administrating a fair number of virtual machines, each one dedicated to some task in the overall system. When we need to administrate them, we typically log in as root, since the only time we log in to the machines at all are when we need to perform administrative tasks in them. We do not use sudo, since every command we do will typically be a sudo command.

We would prefer to keep our accounts separate on these machines, to give us separate .bash_history, see when the other one was last logged in, etc. To do that, we will need two accounts with full root permissions.

One method is to change our normal user accounts to have UID=0 GID=0, i.e. the same as root, however I was dissuaded from that solution in this question: Are there any gotchas with granting a user root privileges by making them UID=0 GID=0?

[That question is the same as this, up to here]

The answer in that question was to use sudo, but as I mentioned, sudo is very inconvenient for our use case. Almost all commands done on those VMs are sudo-commands (and | sudo tee >\dev\null for every output redirect is mind numbing!), so sudo is likely more inconvenient than having separate histories and other account logging is an advantage.

My follow up question then becomes: Is there a reliable way to make several user accounts behave as root, apart from sudo? Or is there a way to make sudo more convenient (apart from sudo -i which defeats the purpose).

Answer 1

If you use sudo -s your $HOME is not updated, so your shell history is kept within your own account.

(Bear in mind that other configuration/history files, such as those created by vim, are also created as root. This means that you may end up with files owned by root in your home directory. This can create "interesting" situations when you want to modify them without being root, and occasionally you'll need to run something like chown -R myusername "$HOME" to fix it.)

Answer 2

Here's how we handled this at a previous job.

First, we had a secure bastion host that admins logged into for all root access to target machines. This host had a special keymaster account configured which held private keys corresponding to root on the target hosts. (We also had a system where new hosts would automatically register themselves. But that's outside of the scope here.)

Admins would log into this bastion host with user-level accounts, and then connect out to the target systems.

Except for the few of us with access to root on the bastion host itself, no admin could actually access the keys directly; instead, they used a connect command run under sudo (as keymaster, not root) to connect. That connect command set the environment variable REMOTE_ADMIN to be the name of the connecting user, and connected as root to the target system.

Then, the remote systems were set to have AcceptEnv=REMOTE_ADMIN in sshd_config, and .bashrc files to set BASH_HISTORY to ~/.bash_history-$REMOTE_ADMIN.

With this setup, the different .bash_history files aren't secure records, but they're at least distinct for the purposes of non-malicious looking back at what happened. The security record is on the bastion host, showing who connected when. (We used 2FA for the sudo connect command, too.)

Additionally, short of subverting the hosts, there's no need to worry about root access outside of the designated system (whether malicious or just for "convenience"). And while keys can be retired, there's no need to do so just because someone's access level has changed.

You could use all or part of this solution; simply having .bash_history-$SUDO_USER might be sufficient, depending on what you're really trying to accomplish.