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

Community
  • 1
columbo
  • 219
  • Have a look at the answers to this question http://unix.stackexchange.com/questions/1052/concern-about-logging-in-as-root-overrated – user9517 Dec 14 '10 at 08:56
  • 1
    duplicate of http://serverfault.com/questions/137362/does-disabling-root-login-enhance-security – Posipiet Dec 14 '10 at 08:56
  • All the answers can be summarised as “defense in depth”, which is a good practice to have. – Jeremy Visser Dec 14 '10 at 13:17

6 Answers6

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.

Posipiet
  • 1,735
  • 14
  • 13
  • 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 '10 at 09: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 '10 at 09: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 '10 at 09: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 '10 at 09:23
  • sudo your_favorite_editor /etc/ssh/sshd_config from a shell. – user9517 Dec 14 '10 at 09:35
  • I solved this by installing gksu from the gnome add/remove programs. Then you can create a launcher shortcut that runs the command gksu gedit. My installation did have a bug where by gksu couldn't find gksu-run-helper. So I copied gksu-run-helper (using the root command line) from /usr/lib/libgksu to /usr/lib64/libgksu (had to create the latter dir) and it works fine. – columbo Dec 14 '10 at 10:31
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.

Kjetil Joergensen
  • 6,074
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).

MadHatter
  • 80,590
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.

Jayakrishnan T
  • 298
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.
jldugger
  • 14,462
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.

cagenut
  • 4,858