Results 1 to 16 of 16
-
05-16-2007, 02:19 PM #1Junior Guru Wannabe
- Join Date
- Nov 2004
- Posts
- 31
Disable Direct Root Login - Step by Step Instructions
Hi,
I tried to disable direct root login but had to struggle to find step-by-step instructions and have written the steps one needs to follow to disable direct root login.
This is an additional security measure where we prevent direct root logins and instead create a user to login and then use a command ‘su –‘ to gain root privileges.
The only risk in this procedure is that you may prevent root login but forget to add the user to the wheel group - effectively locking yourself out of the system.
Follow the steps below and you will not face a problem.
STEP 1: Let us create a user and add it to the wheel group.
For e.g. we want to create a user neonix and give him root privileges.
SSH into your server as root and follow the below commands to create a user.
groupadd neonix
useradd neonix –gneonix
passwd neonix
enteryouruserpasswordhere
verifyyouruserpasswordhere
// Please note -g in the second line
// You can replace neonix with any username of your choice.
STEP 2: Add user to wheel group.
Use your browser to Login to your WHM panel and click on Manage Wheel Group Users.
You will see the user you just added (neonix). Select the user and click ‘Add to group’.
You will see that the user has been added –
Users Currently in the wheel group root,neonix
You have successfully added a user to the 'wheel' group who will be able to 'su -' to root.
LOGOUT OF SSH
Before we disable root login, let us check if the user can login and su – to gain root privileges.
SSH into your server as 'neonix'
Login as: neonix
Password : enteryouruserpasswordhere
su –
password: enter root password here
You have successfully logged in and have root privileges. Now let us disable root login.
STEP 3: Disable Direct Root Login
(The below steps are from webhostgear.com)
1. Copy and paste this line to edit the file for SSH logins
pico -w /etc/ssh/sshd_config
2. Find the line
Protocol 2, 1
3. Uncomment it (Remove #) and change it to look like
Protocol 2
4. Next, find the line
PermitRootLogin yes
5. Uncomment it (Remove #) and make it look like PermitRootLogin no
6. Save the file Ctrl+X then Y then enter
7. Now you can restart SSH
/etc/rc.d/init.d/sshd restart
Now, no one will be able to login to root with out first logging in as 'neonix' and 'su -' to root, and you will be forcing the use of a more secure protocol.
Just make sure you remember both passwords!
-
05-16-2007, 04:20 PM #2
Nice tutorial for making people like me do extra work. I mean come on, the systems admin has nothing better to do than to jump through your mysterious hoops for minor layers of security, right? Nothing better at all.
Realistically, you don't need to "disable root login". In fact, doing so will ALWAYS cause delays when working with a loaded down server, or when specific "login instructions" can't be found (it happens, you're on the road and you can't login from your mobile device. Damn, gotta wait till you get back home to do this). It happens to everyone from time to time.
The proper solution? Use PROPER security, not jerry rigged "layers" of security that don't provide but 1% of security. If you MUST deny root login, at least have the courtesy to allow those that know what they're doing to login using ssh keys.
This is merely an inconvenience and won't really solve anything.
Does it stop hacker X from getting access to your server? No
Does it stop hacker X from gaining ROOT access? Again, no
Does it stop hacker X from screwing up your server? Again, no
SO, you have a "layer" of security that merely disables the most important account on a whim. Nice one.Tom Whiting, WHMCS Guru extraordinaire
Linux problems? WHMCS Problems? Give me a shout
Check out my WHMCS Addons
-
05-17-2007, 03:23 AM #3Web Hosting Evangelist
- Join Date
- Aug 2002
- Posts
- 484
Disabling direct root logins to servers is a great way to help secure a server.
That way, if someone did try to break into your server, they would have to figure out a username on your system that allows super user access first. It's almost like having the username as a password too.
-
06-29-2007, 02:14 PM #4Web Hosting Master
- Join Date
- Jul 2006
- Posts
- 791
Dude, disabling root login exponentially increases your security. With it enabled, half the battle is won - a potential cracker already has a valid user name; root. With it disabled a potential cracker not only has to guess a valid password, but also a valid username.
This is a really, really good way to increase security.
-
06-29-2007, 02:46 PM #5
Wrong
This stops nothing, and it causes more issues than it stops.
With PROPER password measures in place, "root" will never be cracked.
Does this STOP anything? Absolutely not.
Does this stop "web scripts"? Absolutely not
Does this stop the user from getting a user list? nope
So, what does this "stop"? Nothing at all.
Does this DELAY things? Sure, because now someone can't login as root directly, BFD. This also delays resolution of problems, because now you have to login as the user, wait for the system load to go down, then do the authentication thing again.
Disabling direct root logins is not a "security measure", it is a delaying tactic, that's all. Instead, if you setup PROPER passwords, or even make it key only, then you have NO delay logging in and resolving issues, and NO problems whatsoever when it comes to cracks.Tom Whiting, WHMCS Guru extraordinaire
Linux problems? WHMCS Problems? Give me a shout
Check out my WHMCS Addons
-
06-29-2007, 02:52 PM #6Web Hosting Master
- Join Date
- Jul 2006
- Posts
- 791
I guess we'll just have to disagree, then.
I think that it's pretty simple math that guessing two account passwords is harder than guessing one, but you don't see it that way.
-
07-04-2007, 02:19 PM #7Newbie
- Join Date
- Jan 2007
- Location
- egypt
- Posts
- 11
installing BFD , APF , john the ripper from openwall.com/john/ to know if passwords on your server can be broken , LES from rfxnetworks.com to enforce root-only permissions on system binaries (binaries that have no place being
executed by normal users) , is a great way to secure any server
-
07-04-2007, 02:46 PM #8Web Hosting Master
- Join Date
- Jul 2006
- Posts
- 791
-
01-12-2008, 02:26 PM #9WHT Addict
- Join Date
- Aug 2007
- Location
- Minneapolis
- Posts
- 111
You are wrong on so many levels. Disabling remote root login or even hindering the usage of root is the PROPER security protocol. Hardening software such as SELinux do exactly this.
I'd argue SSH-keys are much worse than passwords. Of course, it's unbelievably hard to brute force an SSH-key but if the ~/.ssh/authorized_keys is compromised, all of the systems contained within it are compromised. A good password is much better.
Does it stop hacker X from getting access to your server? It increases the time to brute force not only a password but a username an password as well. If remote root login isn't disabled, the hacker will try to brute force root first. Now if the brute force "dictionary" contains a billion combinations of passwords (and root's password is in it) and you can try 5 passwords per second (very unlikely), that's
1 000 000 000 passwords / 5 passwords per second = 200 000 000 seconds
((200 000 000 / 60) / 60) / 24 / 365 = 6.34 years
Over 6 years maximum to brute force a good password and if it the username isn't known either, it's number of usernames in your dictionary times a maximum of 6 years to brute force the password per account.
An example is if you have a thousand usernames and it takes 6 years to go through all of the possible passwords per username and being very unlucky, the absolute last username and password combination you try is the correct one.
1 000 usernames * 6 years per username = 6000 years to break in compared to only 6 years if remote root login isn't disabled. Adding another layer of pseudo-security by disabling remote login of known accounts to make it more computationally intensive is the whole idea behind key encryption, no?
If you disagree disabling remote root logins, you might as well start using 16 bit encryption or simple XOR as your SSH ciphers. Why use all that processing power on "strong" ciphers when they don't stop people breaking into your computer?
-
01-13-2008, 04:34 AM #10Junior Guru
- Join Date
- Jul 2004
- Location
- Athens, Greece
- Posts
- 209
I'll agree with Jon. Obviously bruteforcing the username and then bruteforcing two passwords (or one password and then find some vulnerability to gain root) is harder than bruteforcing root password.
After all, nobody forces you to use it. An alternative security measure (that linux-tech probably already uses to make his life easier) would be to use SSH keys insteadSharkTECH Internet Services
http://www.sharktech.net
DDOS Firewalled Dedicated Servers
Managed Services / IRC Allowed
-
01-14-2008, 11:08 AM #11New Member
- Join Date
- Jan 2008
- Posts
- 2
Hello,
I had disable it, but how can i return it again
thanx
-
01-15-2008, 02:10 AM #12WHT Addict
- Join Date
- Aug 2007
- Location
- Minneapolis
- Posts
- 111
-
07-19-2008, 03:46 PM #13Web Hosting Evangelist
- Join Date
- Jul 2002
- Location
- New York, USA
- Posts
- 467
Sorry I had to open an old thread, but this advice is just sooo bad and had to comment on it.
web scripts, at least on a shared host, should be running as the account' UID/GID, not apache. They are properly sandboxed. If the kernel and software is updated properly, how can they gain root access? Sandboxing the name of the game.
Does this stop the user from getting a user list? nope
So, what does this "stop"? Nothing at all.
Does this DELAY things? Sure, because now someone can't login as root directly, BFD. This also delays resolution of problems, because now you have to login as the user, wait for the system load to go down, then do the authentication thing again.
Are you that lazy that a few extra keystrokes to get root access? Hell most ssh clients have macro keys available. Press one button and you are in as root. Add ssh keys for your initial login and it's pretty much painless. ssh key ARE more secure than passwords and disable ssh password login on any VPS/server that doesn't have customer access.
Disabling direct root logins is not a "security measure", it is a delaying tactic, that's all. Instead, if you setup PROPER passwords, or even make it key only, then you have NO delay logging in and resolving issues, and NO problems whatsoever when it comes to cracks.
- If you manage multiple servers with multiple sysadmins, if you let go of one sysadmin, all root server passwords must be changed. Giving each admin a user which then they must get root allows for easier hiring/firing. Try your setup with consultants.
- each admin can also be monitored/audited of what commands they did. with just using root user no way to easily figure this out.
- removing root DOES increase security. If the root username/password cannot be knocked via ssh/ftp/etc. that's one additional level of protection. Many passwords chosen aren't as secure as you think.
- delaying root access to hackers? Doesn't that help with security? If you have the proper monitoring/auditing in place any delays you add is in your favor to catch the hacker before real damage occurs.Last edited by empoweri; 07-19-2008 at 03:56 PM.
Larry Ludwig
Empowering Media
HostCube - Proactively Managed Xen based VPSes
Empowering Media - The Dev Null Blog
-
07-19-2008, 08:23 PM #14Disabled
- Join Date
- Dec 2002
- Location
- chica go go
- Posts
- 11,876
I support disabling password authentication completely, run sshd on an alternative port, disable root login, and install portsentry on a large range of ports to keep people from port scanning to find where they can find sshd.
-
07-20-2008, 12:48 AM #15Web Hosting Master
- Join Date
- Jul 2006
- Posts
- 791
Anyone that disagrees with key based root login is an inexperienced boob.
Period.
-
07-21-2008, 10:21 PM #16Aspiring Evangelist
- Join Date
- May 2007
- Posts
- 442
I find it easier to login to root with a key rather than a password.
Especially when the passwords are "more or less" random keystroke type passwords.. takes forever to type those.