7

Possible Duplicate:
Why shouldn't root be allowed to login via ssh?

Hi, Why is it safer to not log in as root via SSH? Since the login is SSH protected the root password is not in plain text over the web. Also once you're in you have to SU into root to carry out certain tasks so the root password is still exposed. I suspect I'm missing the point but when I search this I just find the advice but no convincing reasons.

Any advice gratefully recieved.

Thanks C

3

6 Answers 6

12

Two points: 1.) Because Root is always there, and the gain would be so high, it is probable an eventual brute force attack would take place against root. For other users, the username would have to be guessed first. And then the users would have to have permissions. Making the brute force just not worth the effort.

2.) Noone should login as root, and you should only use sudo to do privileged commands. Therefore, there is no reason to log in root at all.

==> probable gain, no loss in disabling root on ssh.

6
  • Thanks for your answer. I see what you're saying, but for me there is some loss in that if for example I wanted to run the command sestatus, from root I just type sestatus and I get the output. From root when I have SUed in from a non root account I have to go to the /usr/sbin/ directory and then do ./selinux. This may seem trivial but when working all day it adds up to alot of time. Is there a way to SU in that makes you inherit all the root executable paths?
    – columbo
    Dec 14, 2010 at 9:15
  • add /usr/sbin/ to your user path. Add yourself to sudoers. Make a macro if you need to. Call the tool with sudo selinux.
    – Posipiet
    Dec 14, 2010 at 9:17
  • 1
    I've just seen the question to the right that explains that su - does the trick with respect to getting the right $PATH.
    – columbo
    Dec 14, 2010 at 9:18
  • The other drawback of not logging in as root is when using VNC remote desktop (via SSH). Alot of desktop applications will ask you for the root password which is great but some do not. E.g if I want to edit my sshd_config file from a user desktop it will not let me as I don't have permissions on that root only file. DOes anyone know a way around that?
    – columbo
    Dec 14, 2010 at 9:23
  • sudo your_favorite_editor /etc/ssh/sshd_config from a shell.
    – user9517
    Dec 14, 2010 at 9:35
8

There's also the aspect of logging. When you su or sudo, it'll log your username, whereas if you log ssh in as root, just your ip-address will be logged. While you usually will be able to correlate an ip address with a certain user, it's still a lot more telling just having the username logged.

3
  • Give him an up-vote, then, columbo. I will, at least.
    – David
    Dec 14, 2010 at 10:27
  • 1
    I tried but I can't, I haven't got the reputation yet, need 1 more point.
    – columbo
    Dec 14, 2010 at 10:32
  • Thanks for the vote whoever it was I now have the reputation to up this one...
    – columbo
    Dec 14, 2010 at 10:45
1

What posipiet said, plus: it means two sets of trusted information are needed to get root access, not just one; the root password on its own becomes useless, and can only be leveraged alongside a regular user account (and if access to su is restricted, only alongside a trusted user account).

1

well everyone knows that 'root' (the username) is the admin of your box, so by denying 'root' remote access to ssh into your box you are making it just a wee bit harder for the hackers to get into your box since now they will have to guess a username on your box.

  1. As root, vi /etc/ssh/sshd_config

  2. In there find (or create) a line that reads

Quote

#Authentication: #LoginGraceTime 120

PermitRootLogin no

#StrictModes yes

The line PermitRootLogin no is the important one. Note there is no # in front of it.

  1. Once you have made thos changes, save the file (esc then :wq).

  2. Restart sshd (service sshd restart).

With this line root cannot ssh into the box. To become root, ssh in as a normal user then use su - to become root once logged in.

1

The purpose is twofold:

  1. By disabling root SSH, attackers have to now guess passwords and accounts. (you can also just disable passwords entirely and rely on PKI...)
  2. By disabling root SSH, we have a stronger identification and logging method. So if we audit the server after an attack, we can see not only which IP logged in, but with who's credentials. Some places even disable SU and require admins to use sudo, which reduces the chances of people leaving a terminal window open to a passerby attacking, and generates more log data about who did what.
0

"root" holds a near religious status in the world of unix/linux server administration almost entirely because of the history of those OS's use as multiuser systems. back when your company, department, or college had a server the concept of being all powerful among dozens or hundreds meant something.

Now, especially in modern virtualization and/or cloud type environments, its almost a completely vestigial fear. More and more our servers are not only single user, they're single-application, tied together via network services. This is especially true in web clusters, your apache servers are your apache servers, your mysql servers are your mysql servers, it almost wouldn't matter if you ran them in single user mode and everything as root.

Obviously there are exceptions and we're not completely there yet, but the aura of power that tends to come along with the word "root" really applies to your vcenter password or aws private key these days more than a posix account on a few app servers.

Not the answer you're looking for? Browse other questions tagged .