It is a very common recommendation to restrict (disallow) login directly to root, even when SSH keys are used. The reasons are infrequently mentioned, but when they are, they are mostly about not sharing the same root password, not using a common SSH key, and identifying which user logged in as root. It is possible to have root allow direct login from a number of different users each having their own key, but this does not seem to log which was used, so I presume this is the reason this method is not suggested.

Requiring the use of sudo by users does still create difficulties in things like file transfers, especially preserving metadata (cannot stage files in a non-root area because some metadata is lost).

Ages ago when I worked in a Solaris shop, we used multiple root user names, each of which had UID and GID number 0, but different names in the /etc/passwd file. We were using passwords then, but this allowed each person who logged in to root to have their own password. If someone left the company, revoking their access was easy (not really ... anyone could have planted any of many means to get back in since they had root access to do this). This method then had not any real benefit over logging in as their own user and doing "su -" (no sudo back then).

My job after that was at an ISP that became a BSD/Linux shop. And I copied the same root aliasing trick. But I extended it to give each root alias user their own home directory, too. This allowed different usernames to have different .ssh/authorized_keys files. So we could now use tools like rsync via ssh to do direct file transfers as root and retain all metadata.

Jump forward many, many years and I now have a situation where doing this would be useful because of multiple users that need to access as root directly with the ability to user ssh based tools like rsync. At the moment I've set this up as multiple keys in /root/.ssh/authorized_keys. But I am wanting to switch over to the alias root scheme I did long ago. Unfortunately, I never did investigate if that scheme has any security issues that might make it worse than other methods.

Of course NO METHOD that grants full root access in the end is ever secure. You must trust that your users with root access will not do bad things, like installing backdoors.

My question is this: Is the root alias scheme any more dangerous, security wise, than the other methods? And if it is more dangerous, what tradeoffs might I need to explore to decide if I should still use this method or avoid it? Would YOU use it? Do you use it?

You should use sudo instead. It can be configured so the sudoer enters his own password. This allows keeping the root password secret. Sudo commands are logged. Also consider using kernel auditing.

I don't follow what kind of metadata you are talking about. User attributes? What do you mean by staging files.

The only difficulty I have with sudo is redirecting output to a file. The redirection occurs before sudo is run, as the real user.

Internally the kernel and commands only use the UID and Real UID. A log entry may be false when an /etc/password lookup was used to print the user name. The user printed in some log entries may be due to the order of users in /etc/password.

1 members found this post helpful.

given you can create a shell with "sudo -i" the redirection issues disappear then, and that's a much more appropriate comparison to a direct root login.

From my perspective this root alias approach sounds horrific, but I am struggling to really significantly justify my gut reaction.

I should have mentioned that UNIX got its name because it has a single super user, unlike the Multics project it was based on.

Another problem is that each alias root user has root powers for everything. They shouldn't when performing commands that don't require it. You are allowing root logins -- aliased but still root logins. Maybe the OP has using su from sally to sallyroot in mind. The log would have contained sally's name running su anyway.

Having a user name other than root may influence the users behavior out of habit. You see the > prompt of a regular user and may unconciously rely on regular user restrictions.

I'm moving away (have moved away) from using passwords. SSH key passphrases are the way to go, IMHO.

The problem with sudo is that some programs that communicate with ssh just don't do it. One example is rsync. But there are many and I don't want to be in the business of juggling and wrapping these so they will do the "sudo" command, or "sudo -i" command, each time.

And so do users authorized to do "sudo". The difference is that aliased root logins are direct so I don't have to modify applications that use ssh.

Yes, that can be a risk. I could tell them to use sudo when doing things manually. But the scripts/apps that need to use root access would be using the root alias login so they don't need to be modified.

These are people I have to trust. They are trusted enough to be hired and given root level access by some means. A user with sudo access can do damage. They do have to make an extra effort to do so by typing "sudo -i". It still looks like a risk of accidentally being empowered with root for a command not intended to be done that way, vs. having to do workarounds to do various scripts and tools that work through ssh access. If it were all just manual commands, this thread would not have been started.

For users doing manual commands, that works. But I'm dealing with more than that.

It's definitely way out of the norm. Even though I have used this approach in the past, I'm now more security conscious, and want to see what risks this approach adds that others do not. One suggested in this thread is users (who are given root access) habitually using it when they don't need to do things as root. I'm perhaps a bit more worried someone will leave a window sitting around with root access logged in. But that can happen with either root alias naming or with the "sudo -i" method.

I see the root alias method as an advantage over the plain root method (login directly as root when automated things need to be done). I'm thinking about even having root alias names for functional roles, too ... such as the backup server which runs rsync and logs in as user root (via an ssh key of its own specifically for backups which I can remove from authorized_keys if it gets compromised), logging in as user rootbackup (and obviously the distinct ssh key). Then I can look at logs and see rootbackup logged in once during the backup window and feel OK, or see rootbackup logged in outside the backup window and know something is wrong, or see rootbackup logged in a few times during the backup window and know that I need to address a network issue with backups (the backup script retries every 3 minutes during the window).

That's not quite true. In sudoers you specify exactly which commands a user can run as another user. And that goes for each one user.

You can allow only the commands needed for the script(s), maybe with NOPASSWD if they can't be harmful in some way.

Well what are the specific issure you don't feel can be solved here?
Well it *can* happen with sudo, but there are ways to mitigate it somewhat. I don't think there's a way to drop out of a sudo -i invoked shell after a timeout though. One thing that sudo does give you though is a sudo aware shell. you always have access to environmental variables, like SUDO_USER which you can use to see what the invoking user was. I believe there are further ways to leverage security and auditing within sudo, but I've not gone too deep into it.
A backup manager should never need root access. It's certainly possible to create a backup scenario where you need root access, but that would be indicative of a poorly designed process in the first place.

In my case the "users" are system administrators. They do need access to everything. The root aliasing trick isn't intended for other cases.

I don't think sudo easily allows programs that use ssh in some way (rsync is one example). Why implement a wedge program that runs expect to inject "sudo ..." when I normally just use root (when I'm the only sysadmin, I just use it straight).

I don't know if by "backup manager" you mean a program directing other programs to do backups, or is the one that actually does the backups. Files can be owned by a few users and have a variety of permissions. The process doing the backups needs root ability. Of course it could be designed to run as an suid-root executable. But I didn't find any such feature in rsync.