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

  • Doesn't sudo -s work for you? Commented Aug 14, 2017 at 19:37
  • Same problem as sudo -i, it makes us into root and we loose the separated account logging. Commented Aug 14, 2017 at 19:38
  • 1
    Doesn't set $HOME so you shouldn't be seeing that behaviour Commented Aug 14, 2017 at 19:39
  • Wow! You are right! My user account history is what gets updated, not the root history! Commented Aug 14, 2017 at 19:49
  • sudo -s depends on settings in /etc/sudoers. On Red Hat family systems, $HOME is reset. (It's really easy to cause problems for yourself otherwise, so I'm kind of surprised this isn't the default elsewhere.)
    – mattdm
    Commented Aug 15, 2017 at 13:52

2 Answers 2


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

  • 1
    This one really seems to give me what I want! I just made the assumption that sudo -s would put my history in /root, but I didn't check! Doh! Commented Aug 14, 2017 at 19:56
  • We will probably always do sudo -s immediately after log in on these machines, so likely all files in our home directories will be owned by root, but since we will always be root anyway, that will be no problem :-) Commented Aug 14, 2017 at 20:00
  • 1
    @00prometheus forewarned is forearmed, and all that... Commented Aug 14, 2017 at 20:18
  • This does not work out of the box on Fedora, RHEL, or CentOS. Both always_set_home and env_reset are on in the default /etc/sudoers. I think this is a sensible default and the caveats in the "Bear in mind..." parenthetical are pretty important, and I'd really recommend against this.
    – mattdm
    Commented Aug 14, 2017 at 20:27
  • Thanks for that heads-up! We are Ubuntu based, but we should keep that in mind when distributing /etc/sudoers to the VMs. And yes, there will likely be one caveat or another to bite us at some point, but this is close enough to make me happy! At least I will be happy until I have tried it; later on we will see what my mood is after I have tried it! ;-) Commented Aug 14, 2017 at 20:32

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.

  • This is at least gives some mitigation to the problem! It doesn't give the full logging a real account would give, but at least we get our own histories! Commented Aug 14, 2017 at 19:20
  • You can't really have full logging of a system where you're letting people have root, anyway. We also used a version of bash which sent all commands to remote syslog, but this is easy to circumvent. The audit logs are a little better, but... when you've got people as root, it really comes down to trust.
    – mattdm
    Commented Aug 14, 2017 at 19:22
  • Well, trust isn't the problem, it is more about having a way of going back to see what was done and when it was done for those times our manual logs are insufficient. Commented Aug 14, 2017 at 19:24
  • Any system must have at least one root admin, and any critical system must have at least one redundancy, so there must always be at least two root admins. I can't believe there is no commonly used best practice solution to this! Commented Aug 14, 2017 at 19:32
  • 3
    I think best practice these days is to have no humans log into boxes directly ever. Changes go into config management which goes through code review and is then pushed to systems. If something goes really wrong, you blow up the machine and build a new one.
    – mattdm
    Commented Aug 14, 2017 at 19:45

You must log in to answer this question.

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