Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I currently have a VPS server which I use to host a number of small websites. I have cPanel and WHM on the server, which includes cphulk which helps blocks brute force login attempts. The root account on my server gets targeted a couple of times a day, and after a brute force attempt, the account is looked for a period of time - meaning the root account is unable to login.

What I want to do is create another user with the same privileges as the root account with a different username (say bob123 for example) to get around the issue that it completely blocks access to the root account.

I'm pretty new to VPS & Linux, so apologies if the above doesn't make sense / seem practical - any advice is appreciated!

share|improve this question

migrated from stackoverflow.com Nov 21 '11 at 19:58

This question came from our site for professional and enthusiast programmers.

2 Answers 2

You might consider modifying /etc/sudoers to allow your user to use sudo to run commands as root. It's a bit safer than logging in as root or creating another root user.

You can easily modify the file by running visudo. (OK, "easily" is a bit of an overstatement if you don't know vi.) If you add a line like

bob123   ALL=(ALL) ALL

to /etc/sudoers, then bob123 can say sudo some_program to run some_program with root privileges. They'll be prompted for their password (not root's!). (If you don't want a password prompt, change that last ALL to NOPASSWD: ALL.)

For more flexibility, you can do things like specify a group instead of a user (like %admins or something) or specify a list of programs to allow for a user (replace the last ALL with a comma-separated list of programs), or even set which user a user can run stuff as (replace the (ALL) with (user : group)). man sudoers for info on what all you can do. Personally, i prefer to have a group that i add people to when i want them to have sudo access, but let them do whatever once they have it. (If someone's in my sudoers group, it's probably me anyway. :))

(Note, this requires that sudo be installed. For Fedora/RHEL/CEntOS, it's as easy as yum install sudo if you don't already have it. For other flavors of Linux, consult the documentation.)

share|improve this answer
I think one should add that the path to some_program can be given directly. No need to give ALL. Besides, the absolute path should be given. One can also create aliases for commands and users ... man sudoers ;) –  0xC0000022L Nov 21 '11 at 19:28
I personally prefer to have a group and add people to it as needed -- keeps from having to modify the sudoers file all the time. But considering the original goal (creating another user that has all the power of root), ALL is about the only useful way to accomplish that. –  cHao Nov 21 '11 at 19:33

Assuming this is about SSH (because if it's not I would recommend to change the hoster as it means that the actual root account is exposed via services it shouldn't be - although I personally count SSH in there).

How about using this inside your /etc/ssh/sshd_config:

PermitRootLogin no

This will prevent login via SSH (and brute-force attempts), while leaving the root account in place and untouched. Alternatively simply disallow the use of passwords and start using public/private key pairs to authenticate (PubkeyAuthentication yes and PasswordAuthentication no).

Also, any kind of trickery is probably going to fail. Though you can rename the account root or even simply create another "alias" of it on most Linuxes, the user ID of 0 will be the clue for most programs that this is the super user.

share|improve this answer
Renaming the root user brings its own bunch of issues -- some software assumes that UID 0's username is "root", and will use that username rather than whatever you renamed it to (and will thus fail if the user "root" no longer exists or doesn't have root permissions). –  cHao Nov 21 '11 at 20:33
Software relying on the user name rather than the well-known UIDs should simply be abolished ;) –  0xC0000022L Nov 22 '11 at 15:24
Agreed. But it's out there. :) And the fun part: last i checked, su itself was one of those programs. (I experimented with changing root's name, but changed it back once i realized just how much stuff breaks when root isn't "root". :P) –  cHao Nov 22 '11 at 16:23
+1 for disallowing remote root login (or at least making it keys-only or OTP-only, which everyone should consider doing for all accounts anyway) ; -1 for renaming root (this is the most blatant violation of the Policy of Least Astonishment one can commit, and buys only a marginal increase in security - Why make your system different from every other *nix box?) –  voretaq7 Nov 28 '11 at 16:43
@voretaq7: consider the question, though. This would probably fail anyway, as I already wrote. Perhaps re-read my statement. I'm not endorsing it in any way, actually the opposite. Just explaining that the option exists ;) –  0xC0000022L Nov 28 '11 at 18:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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