In our team we have three seasoned Linux sysadmins having to administer a few dozen Debian servers. Previously we have all worked as root using SSH public key authentication. But we had a discussion on what is the best practice for that scenario and couldn't agree on anything.

Everybody's SSH public key is put into ~root/.ssh/authorized_keys2

  • Advantage: easy to use, SSH agent forwarding works easily, little overhead
  • Disadvantage: missing auditing (you never know which "root" made a change), accidents are more likely

Using personalized accounts and sudo

That way we would login with personalized accounts using SSH public keys and use sudo to do single tasks with root permissions. In addition we could give ourselves the "adm" group that allows us to view log files.

  • Advantage: good auditing, sudo prevents us from doing idiotic things too easily
  • Disadvantage: SSH agent forwarding breaks, it's a hassle because barely anything can be done as non-root

Using multiple UID 0 users

This is a very unique proposal from one of the sysadmins. He suggest to create three users in /etc/passwd all having UID 0 but different login names. He claims that this is not actually forbidden and allow everyone to be UID 0 but still being able to audit.

  • Advantage: SSH agent forwarding works, auditing might work (untested), no sudo hassle
  • Disadvantage: feels pretty dirty - couldn't find it documented anywhere as an allowed way

What would you suggest?

  • 2
    About your "couldn't find it documented anywhere as an allowed way" statement: Have a look to the -o flag in the useradd manual page. This flag is there to allow multiple users sharing the same uid. – jlliagre May 21 '12 at 11:38
  • 6
    Can you explain what you mean by "SSH agent forwarding breaks" in the second option? We use this at my work and ssh agent forwarding works just fine. – Patrick May 21 '12 at 12:01
  • 4
    You should ssh out from your non-root account rather than from within sudo. – Random832 May 21 '12 at 12:33
  • 4
    Another consequence of sudo method: You can no longer SCP/FTP as root. Any file transfers will first need to be moved into the person's home directory and then copied over in the terminal. This is an advantage and a disadvantage depending on perspective. – user606723 May 21 '12 at 14:43
  • 1
    Why aren't puppet/chef/ansible-type systems being considered? – Alex Holst May 21 '12 at 20:29

The second option is the best one IMHO. Personal accounts, sudo access. Disable root access via SSH completely. We have a few hundred servers and half a dozen system admins, this is how we do it.

How does agent forwarding break exactly?

Also, if it's such a hassle using sudo in front of every task you can invoke a sudo shell with sudo -s or switch to a root shell with sudo su -

  • 10
    Rather than disable root access by SSH completely, I recommend making root access by SSH require keys, creating one key with a very strong keyphrase and keeping it locked away for emergency use only. If you have permanent console access this is less useful, but if you don't, it can be very handy. – EightBitTony May 21 '12 at 13:02
  • 17
    I recommend disabling root login over SSH for security purposes. If you really need to be logged in as root, log in as a non-root user and su. – taz May 21 '12 at 14:29
  • +1.. I'd go further than saying "The second option is the best". I'd it's the only reasonable option. Options one and three vastly decrease the security of the system from both outside attacks and mistakes. Besides, #2 is how the system was designed to be primarily used. – Ben Lee May 23 '12 at 18:28
  • 2
    Please, elaborate on sudo -s. Am I correct to understand that sudo -i is no difference to using su - or basically logging in as root apart from additional log entry compared to plain root login? If that's true, how and why is it better than plain root login? – PF4Public Jun 3 '16 at 20:32

With regard to the 3rd suggested strategy, other than perusal of the useradd -o -u userXXX options as recommended by @jlliagre, I am not familiar with running multiple users as the same uid. (hence if you do go ahead with that, I would be interested if you could update the post with any issues (or sucesses) that arise...)

I guess my first observation regarding the first option "Everybody's SSH public key is put into ~root/.ssh/authorized_keys2", is that unless you absolutely are never going to work on any other systems;

  1. then at least some of the time, you are going to have to work with user accounts and sudo

The second observation would be, that if you work on systems that aspire to HIPAA, PCI-DSS compliance, or stuff like CAPP and EAL, then you are going to have to work around the issues of sudo because;

  1. It an industry standard to provide non-root individual user accounts, that can be audited, disabled, expired, etc, typically using some centralized user database.

So; Using personalized accounts and sudo

It is unfortunate that as a sysadmin, almost everything you will need to do on a remote machine is going to require some elevated permissions, however it is annoying that most of the SSH based tools and utilities are busted while you are in sudo

Hence I can pass on some tricks that I use to work-around the annoyances of sudo that you mention. The first problem is that if root login is blocked using PermitRootLogin=no or that you do not have the root using ssh key, then it makes SCP files something of a PITA.

Problem 1: You want to scp files from the remote side, but they require root access, however you cannot login to the remote box as root directly.

Boring Solution: copy the files to home directory, chown, and scp down.

ssh userXXX@remotesystem, sudo su - etc, cp /etc/somefiles to /home/userXXX/somefiles, chown -R userXXX /home/userXXX/somefiles, use scp to retrieve files from remote.

Very boring indeed.

Less Boring Solution: sftp supports the -s sftp_server flag, hence you can do something like the following (if you have configured password-less sudo in /etc/sudoers);

sftp  -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \

(you can also use this hack-around with sshfs, but I am not sure its recommended... ;-)

If you don't have password-less sudo rights, or for some configured reason that method above is broken, I can suggest one more less boring file transfer method, to access remote root files.

Port Forward Ninja Method:

Login to the remote host, but specify that the remote port 3022 (can be anything free, and non-reserved for admins, ie >1024) is to be forwarded back to port 22 on the local side.

 [localuser@localmachine ~]$ ssh userXXX@remotehost -R 3022:localhost:22
Last login: Mon May 21 05:46:07 2012 from
This is a private system; blah blah blah

Get root in the normal fashion...

-bash-3.2$ sudo su -
[root@remotehost ~]# 

Now you can scp the files in the other direction avoiding the boring boring step of making a intermediate copy of the files;

[root@remotehost ~]#  scp -o NoHostAuthenticationForLocalhost=yes \
 -P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password: 
resolv.conf                                 100%  
[root@remotehost ~]#  



Problem 2: SSH agent forwarding: If you load the root profile, e.g. by specifying a login shell, the necessary environment variables for SSH agent forwarding such as SSH_AUTH_SOCK are reset, hence SSH agent forwarding is "broken" under sudo su -.

Half baked answer:

Anything that properly loads a root shell, is going to rightfully reset the environment, however there is a slight work-around your can use when you need BOTH root permission AND the ability to use the SSH Agent, AT THE SAME TIME

This achieves a kind of chimera profile, that should really not be used, because it is a nasty hack, but is useful when you need to SCP files from the remote host as root, to some other remote host.

Anyway, you can enable that your user can preserve their ENV variables, by setting the following in sudoers;

 Defaults:userXXX    !env_reset

this allows you to create nasty hybrid login environments like so;

login as normal;

[localuser@localmachine ~]$ ssh userXXX@remotehost 
Last login: Mon May 21 12:33:12 2012 from
This is a private system; blah blah blah
-bash-3.2$ env | grep SSH_AUTH

create a bash shell, that runs /root/.profile and /root/.bashrc. but preserves SSH_AUTH_SOCK

-bash-3.2$ sudo -E bash -l

So this shell has root permissions, and root $PATH (but a borked home directory...)

bash-3.2# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:system_r:unconfined_t
bash-3.2# echo $PATH

But you can use that invocation to do things that require remote sudo root, but also the SSH agent access like so;

bash-3.2# scp /root/.ssh/authorized_keys ssh-agent-user@some-other-remote-host:~
/root/.ssh/authorized_keys              100%  126     0.1KB/s   00:00    
  • I like the hacks. – sjbotha May 21 '12 at 20:16

The 3rd option looks ideal - but have you actually tried it out to see what's happenning? While you might see the additional usernames in the authentication step, any reverse lookup is going to return the same value.

Allowing root direct ssh access is a bad idea, even if your machines are not connected to the internet / use strong passwords.

Usually I use 'su' rather than sudo for root access.

  • 4
    Adding multiple users with the same UID adds problems. When applications go to look up the username for a UID number, they can look up the wrong username. Applications which run under root can think theyre running as the wrong user, and lots of weird errors will start popping up (I tried it once). – Patrick May 21 '12 at 11:59
  • 8
    The third option is just a bloody bad idea. You're essentially breaking the 1:1 relation between UIDs and usernames, and literally everything in unix expects that relation to hold. Just because there's no explicit rule not to do it doesn't mean it's a good idea. – Shadur May 21 '12 at 14:28
  • Sorry, but the third option is a horrible idea. Having multiple UID 0 people logging in is just asking for problems to be multiplied. Option number 2 is the only sane one. – Doug May 21 '12 at 20:01
  • The third option doesn't deserve that many downvotes. There is no command in Unix I'm aware of that is confused by this trick, people might be but commands should not care. It is just a different login name but as soon as you are logged in, the first name found matching the uid in the password database is used so just make sure the real username (here root) appears first there. – jlliagre May 21 '12 at 21:38
  • @Patrick Have you seen this in practice? As much as I tested, then applications pick root user if root user is the first one in /etc/passwd with UID 0. I tend to agree with jlliagre. The only downside that I see, is that each user is a root user and sometimes it might be confusing to understand who did what. – Martin Sep 4 '16 at 18:31

I use (1), but I happened to type

rm -rf / tmp *

on one ill-fated day.I can see to be bad enough if you have more than a handful admins.

(2) Is probably more engineered - and you can become full-fledged root through sudo su -. Accidents are still possible though.

(3) I would not touch with a barge pole. I used it on Suns, in order to have a non-barebone-sh root account (if I remember correctly) but it was never robust - plus I doubt it would be very auditable.


Definitely answer 2.

  1. Means that you're allowing SSH access as root. If this machine is in any way public facing, this is just a terrible idea; back when I ran SSH on port 22, my VPS got multiple attempts hourly to authenticate as root. I had a basic IDS set up to log and ban IPs that made multiple failed attempts, but they kept coming. Thankfully, I'd disabled SSH access as the root user as soon as I had my own account and sudo configured. Additionally, you have virtually no audit trail doing this.

  2. Provides root access as and when it is needed. Yes, you barely have any privileges as a standard user, but this is pretty much exactly what you want; if an account does get compromised, you want it to be limited in its abilities. You want any super user access to require a password re-entry. Additionally, sudo access can be controlled through user groups, and restricted to particular commands if you like, giving you more control over who has access to what. Additionally, commands run as sudo can be logged, so it provides a much better audit trail if things go wrong. Oh, and don't just run "sudo su -" as soon as you log in. That's terrible, terrible practice.

  3. Your sysadmin's idea is bad. And he should feel bad. No, *nix machines probably won't stop you from doing this, but both your file system, and virtually every application out there expects each user to have a unique UID. If you start going down this road, I can guarantee that you'll run into problems. Maybe not immediately, but eventually. For example, despite displaying nice friendly names, files and directories use UID numbers to designate their owners; if you run into a program that has a problem with duplicate UIDs down the line, you can't just change a UID in your passwd file later on without having to do some serious manual file system cleanup.

sudo is the way forward. It may cause additional hassle with running commands as root, but it provides you with a more secure box, both in terms of access and auditing.


Definately option 2, but use groups to give each user as much control as possible without needing to use sudo. sudo in front of every command loses half the benefit because you are always in the danger zone. If you make the relevant directories writable by the sysadmins without sudo you return sudo to the exception which makes everyone feel safer.


In the old days, sudo did not exist. As a consequence, having multiple UID 0 users was the only available alternative. But it's still not that good, notably with logging based on the UID to obtain the username.

Nowadays, sudo is the only appropriate solution. Forget anything else.


It is documented permissible by fact. BSD unices have had their toor account for a long time, and bashroot users tend to be accepted practice on systems where csh is standard (accepted malpractice ;)


Perhaps I'm weird, but method (3) is what popped into my mind first as well. Pros: you'd have every users name in logs and would know who did what as root. Cons: they'd each be root all the time, so mistakes can be catastrophic.

I'd like to question why you need all admins to have root access. All 3 methods you propose have one distinct disadvantage: once an admin runs a sudo bash -l or sudo su - or such, you lose your ability to track who does what and after that, a mistake can be catastrophic. Moreover, in case of possible misbehaviour, this even might end up a lot worse.

Instead you might want to consider going another way:

  • Create your admin users as regular users
  • Decide who needs to do what job (apache management / postfix management etc)
  • Add users to related groups (such as add "martin" to "postfix" and "mail", "amavis" if you use it, etc.)
  • Fix permissions (chmod -R g+w postfix:postfix /etc/postfix)
  • give only relative sudo powers: (visudo -> let martin use /etc/init.d/postfix , /usr/bin/postsuper etc.)

This way, martin would be able to safely handle postfix, and in case of mistake or misbehaviour, you'd only lose your postfix system, not entire server.

Same logic can be applied to any other subsystem, such as apache, mysql, etc.

Of course, this is purely theoretical at this point, and might be hard to set up. It does look like a better way to go tho. At least to me. If anyone tries this, please let me know how it went.

  • I should add handling SSH connections is pretty basic in this context. Whatever method you use, do not permit root logins over SSH, let the individual users ssh with their own credentials, and handle sudo/nosudo/etc from there. – Tuncay Göncüoğlu Nov 30 '12 at 17:53

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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