Security Tip: Disable Root SSH Login on Linux
One of the biggest security holes you could open on your server is to allow directly logging in as root through ssh, because any cracker can attempt to brute force your root password and potentially get access to your system if they can figure out your password.
It’s much better to have a separate account that you regularly use and simply sudo to root when necessary. Before we begin, you should make sure that you have a regular user account and that you can su or sudo to root from it.
To fix this problem, we’ll need to edit the sshd_config file, which is the main configuration file for the sshd service. The location will sometimes be different, but it’s usually in /etc/ssh/. Open the file up while logged on as root.
vi /etc/ssh/sshd_config
Find this section in the file, containing the line with “PermitRootLogin” in it.
#LoginGraceTime 2m
#PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
Make the line look like this to disable logging in through ssh as root.
PermitRootLogin no
Now you’ll need to restart the sshd service:
/etc/init.d/sshd restart
Now nobody can brute force your root login, at least.
Daily Email Updates
You can get our how-to articles in your inbox each day for free. Just enter your name and email below:
This is a very smart security tip, especially the reminder to make sure you can still su / sudo without root ssh access!
I often also set up ’su’ so that only certain users can run it using either the wheel or admin group (depending on the flavor of *nix). Something like:
1. Log in as root
2. Add a user that you want to have access to ’su’ to this group.
3. cd to wherever su is located
4. chgroup groupname su
5. chmod 4750 su
If you don’t have console access to the machine, it’s extremely important that you never forget your password, else you’re pretty much locked out of ever getting back into the root account. One way around that problem I found was to create a second account in this group that I never ever use with an incredibly long and complex password that I keep in a safe place.
These are a lot of layers, but IMHO totally worth it when it comes to basic root account security.
Great followup tip!
Always love it when the readers add really useful information.
Ok, help me out here. How is it “insecure” to allow root login over ssh, but “secure” to allow a user with ’su’ or ’sudo’ access login over ssh. If a “hacker” discovers (by brute force, phishing, or whatever) the user’s password with su, or sudo she can do just as much damage as if she found the root password by the same means and logged directly in.
trashman, it is more secure to use a different login name over SSH because the hacker has to first guess the login name AND then the password of that login.
Whereas, if root is enabled over SSH, the hacker knows the login and only needs to guess the password.
Also, sudo can be easily set to a different password, or to tighter restrictions than full root. Then the attacker would have to brute-force two different passwords.
Damn skippy! I love this trick. Although, I like to pretend I’m really paranoid and also do the following:
Assign a dedicated IP to SSH via /etc/ssh/sshd_config
-this IP is to be used ONLY by SSH
Assign a dedicated PORT to SSH via /etc/ssh/sshd_config
-this PORT should only be used by SSH
And of course, set up a firewall to block IPs that conduct port scans.
Now a hacker must….
1) know the IP
2) know the PORT
3) know the login
4) brute force the login pass
5) brute force the root pass
I’d imagine (correct me if I’m wrong) that a hacker will give up before even getting to the login prompt… (or be blocked well before then)
You could add the line
sshd: ALL
to /etc/hosts.deny file and then explicity add the ips i want to allow to /etc/hosts.allow
Although this is only useful for those who have static ip and maybe not recommended if you only have 1 ip you can connect from that is provided to you by your isp for example.
Great comments. I can’t really use the IP restrictions myself, as I am often on the road, and need access from a hotel, internet cafe, or other unpredictable access point. My best friend is the “denyhosts” package, which allows 3 attempts (configurable) at a password, then shuts down the offending source IP for some period like a week. That shuts down brute force attacks pretty fast.
#vi /etc/ssh/sshd_config
….
PermitRootLogin no
….
DenyUsers oracle
———–
and restart service
for solaris10
#svcadm restart ssh
or solaris9
#/etc/init.d/sshd restart
http://it-howtodo.blogspot.com.....r-ssh.html
Can we not restrict based on mac addresses for those on the road? or with dynamic IPs?
Ofcourse even better is to completely disable password authentication and move over to a public key way of authentication.