How-To Geek
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.
Got Feedback? Join the discussion at discuss.howtogeek.com
Comments (24)
Programmer by day, geek by night, The Geek, also known as Lowell Heddings, spends all his free time bringing you fresh geekery on a daily basis. You can follow him on Google+ if you'd like.
- Published 10/5/07
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/2009/06/how-to-disable-users-for-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.
Is it possible to disable other services such telnet, FTP by user account ?
A bit confused – in Crunchbang 8.10 (Ubuntu-based) I don’t have an sshd_config file, only ssh_config. And there is no PermitRootLogin in this file. Does this mean there’s no problem and I can ignore it?
Means that you most probably don’t have a sshd server running, you only have the client
What the default if ‘PermitRootLogin no’ or ‘PermitRootLogin Yes’ is not defined in the config file? Would it by default then still allow direct login as root via SSH ?
Made a mistake.. it should read….What if the default ‘PermitRootLogin no’ or ‘PermitRootLogin Yes’ options are not defined in the config file? Would it by default then still allow direct login as root via SSH ?
@kevin.
yes it would
#command (putting a hash/pound sign first) comments it out as though it’s not there.
so
#permitrootlogin no
is the same as
permitrootlogin yes.
The issue, as I understand it, is not to protect a brute force attack. Even if the passwords are different, it’s only 2x as hard to attack two as attack one.
The issue is audit. If I log in as me and su, there’s an audit trail. If I log in as root, I’m anonymous.
@k
it is much greater than 2 x as hard to guess a random user name and password than to guess a random password alone.
And then, guessing a random password a second time.
I’m surprised nobody pointed this out. Take any password and append the username in front of it–as a part of the password. Put a delimiter in between, say a hyphen, and that makes the password just as hard to guess as the username/password combo in separate fields.
My point is, the password alone can be just as safe as the username/password combo if you add more characters to your password to increase its strength by that amount. So having a separate username doesn’t increase security any more than having a more complicated password.
Actually, we use a different technique that involves 2 steps.
1. Do the above, ie, disable root and create user(s) with privileges to su.
2. Install a VPN (software or hardware) and create configs for each user. Only allow SSH port using the VPN IPs. That keeps the hackers an additional layer, especially if you have certificates for connection.
Hope this helps someone!
An outstanding security tip! I used it and works perfectly!
This last is similar to using iptables to block all incoming traffic who is not reliable.
Il est aussi possible d’ajouter le paquet fail2ban