SEARCH

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.

Lowell Heddings, better known online as the How-To Geek, spends all his free time bringing you fresh geekery on a daily basis. You can follow him on if you'd like.

  • Published 10/5/07

Comments (24)

  1. Matt

    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.

  2. The Geek

    Great followup tip!

    Always love it when the readers add really useful information.

  3. Trashman

    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.

  4. Dean

    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.

  5. xaethos

    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.

  6. TDI

    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)

  7. Dave Casserly

    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.

  8. Matt Warnock

    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.

  9. yendee

    #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

  10. abhi

    Can we not restrict based on mac addresses for those on the road? or with dynamic IPs?

  11. abhi

    Ofcourse even better is to completely disable password authentication and move over to a public key way of authentication.

  12. apit

    Is it possible to disable other services such telnet, FTP by user account ?

  13. Chris Watkins

    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?

  14. Vasko

    Means that you most probably don’t have a sshd server running, you only have the client

  15. Kevin

    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 ?

  16. Kevin

    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 ?

  17. dan

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

  18. K

    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.

  19. Erich

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

  20. David Pesta

    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.

  21. M. Faraz

    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!

  22. Eduardo Lago

    An outstanding security tip! I used it and works perfectly!

  23. Gabriel

    This last is similar to using iptables to block all incoming traffic who is not reliable.

  24. francois

    Il est aussi possible d’ajouter le paquet fail2ban

Get Free Articles in Your Inbox!

Join 134,000 newsletter readers

Email:

Go check your email!