hosted by liquidweb


Go Back   Web Hosting Talk : Web Hosting Main Forums : Web Hosting Talk Tutorials : Hosting Security and Technology Tutorials : Disable Direct Root Login - Step by Step Instructions
Reply

Forum Jump

Disable Direct Root Login - Step by Step Instructions

Reply Post New Thread In Hosting Security and Technology Tutorials Subscription
 
Send news tip View All Posts Thread Tools Search this Thread Display Modes
  #1  
Old 05-16-2007, 02:19 PM
neonix neonix is offline
Junior Guru Wannabe
 
Join Date: Nov 2004
Posts: 30

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!



Sponsored Links
  #2  
Old 05-16-2007, 04:20 PM
twhiting9275 twhiting9275 is offline
Just me
 
Join Date: Sep 2002
Location: Among the corn
Posts: 10,473
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.

  #3  
Old 05-17-2007, 03:23 AM
kerplunk kerplunk is offline
Web Hosting Evangelist
 
Join Date: Aug 2002
Posts: 483
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.

Sponsored Links
  #4  
Old 06-29-2007, 02:14 PM
jonwatson jonwatson is offline
Web Hosting Master
 
Join Date: Jul 2006
Location: Nova Scotia Canada!
Posts: 783
Quote:
Originally Posted by linux-tech View Post
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.
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.

__________________
jonwatson.ca

  #5  
Old 06-29-2007, 02:46 PM
twhiting9275 twhiting9275 is offline
Just me
 
Join Date: Sep 2002
Location: Among the corn
Posts: 10,473
Quote:
Originally Posted by HostingPuppy View Post
With it disabled a potential cracker not only has to guess a valid password, but also a valid username.
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.

  #6  
Old 06-29-2007, 02:52 PM
jonwatson jonwatson is offline
Web Hosting Master
 
Join Date: Jul 2006
Location: Nova Scotia Canada!
Posts: 783
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.

__________________
jonwatson.ca

  #7  
Old 07-04-2007, 02:19 PM
xnor84 xnor84 is offline
Newbie
 
Join Date: Jan 2007
Location: egypt
Posts: 8
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

  #8  
Old 07-04-2007, 02:46 PM
jonwatson jonwatson is offline
Web Hosting Master
 
Join Date: Jul 2006
Location: Nova Scotia Canada!
Posts: 783
Quote:
Originally Posted by xnor84 View Post
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
I had AdminGeekz harden one of my servers and they did this. I didn't even know it could be done, but yeah - I agree. It's excellent.

__________________
jonwatson.ca

  #9  
Old 01-12-2008, 02:26 PM
ximi ximi is offline
WHT Addict
 
Join Date: Aug 2007
Location: Minneapolis
Posts: 109
Quote:
Originally Posted by linux-tech View Post
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.
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?

  #10  
Old 01-13-2008, 04:34 AM
psyxakias psyxakias is offline
Junior Guru
 
Join Date: Jul 2004
Location: Athens, Greece
Posts: 203
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 instead

__________________
SharkTECH Internet Services
http://www.sharktech.net
DDOS Firewalled Dedicated Servers
Managed Services / IRC Allowed


  #11  
Old 01-14-2008, 11:08 AM
almuhajir almuhajir is offline
New Member
 
Join Date: Jan 2008
Posts: 1
Hello,

I had disable it, but how can i return it again

thanx

  #12  
Old 01-15-2008, 02:10 AM
ximi ximi is offline
WHT Addict
 
Join Date: Aug 2007
Location: Minneapolis
Posts: 109
Quote:
Originally Posted by almuhajir View Post
Hello,

I had disable it, but how can i return it again

thanx
Go in /etc/ssh/sshd_config and find the PermitRootLogin entry, set it to yes.

PermitRootLogin yes

  #13  
Old 07-19-2008, 03:46 PM
empoweri empoweri is offline
Web Hosting Evangelist
 
Join Date: Jul 2002
Location: New York, USA
Posts: 466
Sorry I had to open an old thread, but this advice is just sooo bad and had to comment on it.

Quote:
Originally Posted by linux-tech View Post
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
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.

Quote:

Does this stop the user from getting a user list? nope
? user list or not, how does make a system insecure? Grabbing /etc/passwd, while isn't great isn't a security risk if you have other things in place.

Quote:
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.
load to go down?? are you actually stating all hackers make big load spikes?? Buzz wrong. They are much more aware of monitoring systems are in place and, if they are any good, tread very lightly.

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.

Quote:
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.
Sorry but I also disagree with you and is completely bad advice. Giving out direct root access is wrong on so many levels.

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

__________________
Larry Ludwig
Empowering Media
HostCube - Proactively Managed Xen based VPSes
Empowering Media - The Dev Null Blog


Last edited by empoweri; 07-19-2008 at 03:56 PM.
  #14  
Old 07-19-2008, 08:23 PM
ub3r ub3r is offline
Disabled
 
Join Date: Dec 2002
Location: chica go go
Posts: 11,858
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.

  #15  
Old 07-20-2008, 12:48 AM
jonwatson jonwatson is offline
Web Hosting Master
 
Join Date: Jul 2006
Location: Nova Scotia Canada!
Posts: 783
Anyone that disagrees with key based root login is an inexperienced boob.

Period.

__________________
jonwatson.ca

Reply

Related posts from TheWhir.com
Title Type Date Posted
Linux Malware Operation Windigo Infects 25,000 Web Servers Web Hosting News 2014-03-19 11:44:53
MongoHQ Launches New Security Features, Open Sources Startup Security Handbook Web Hosting News 2014-01-30 12:22:00
Are You Prepared for Your Digital Afterlife? Blog 2013-06-27 16:28:32
WHMCS Releases Version 5.2 of Web Hosting Billing Solution Web Hosting News 2013-04-14 22:35:37
SSHD Rootkit in the Wild Blog 2013-02-22 16:44:08


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes
Postbit Selector

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump
Login:
Log in with your username and password
Username:
Password:



Forgot Password?
Advertisement:
Web Hosting News:



 

X

Welcome to WebHostingTalk.com

Create your username to jump into the discussion!

WebHostingTalk.com is the largest, most influentual web hosting community on the Internet. Join us by filling in the form below.


(4 digit year)

Already a member?