FreeBSD, Linux, Technical

WARNING: PermitRootLogin defaults to “yes”

For many yers I have used FreeBSD nearly exclusively. In the BSD tradition, root is pretty well protected — root can not log in from remote unless you put some effort into hooking that up, and local users can only run su if they are members of the wheel group. Because of the nifty sudo tool and my own disinterest in memorizing any more passwords than necessary, I have tended to remain unconcerned with the root password, setting it and storing the thing somewhere, which is a pain, or setting it to something dumb, or just not setting it, depending on the security needs of a given system.

I recently learned a painful lesson from Fedora: not all unices are as protective of the root user. Sure, I knew that in Linux any local user can run su, but OpenSSH isn’t going to allow people to log in as root, right? Wrong!

I had a test box from ASA that shipped with FC3. I made it accessible over the Internet. I added a user for myself, gave him sudo access, and removed the vendor-supplied non-root user. By default, Fedora Core has a firewall that denies inbound SSH access. I took that as evidence that Fedora was operating on the principle of least privilege, and reconfigured the firewall to allow inbound SSH, and let the machine be. A week later I logged in, and kept getting out of memory errors. Before long, I figured out that the box was owned by hackers, and shut it down.

In discussing the event with colleagues, I learned that Fedora defaults to allowing root to log in via SSH. And root‘s password had been left, by me, to the default vendor password, which is well-known. This seems bass ackwards to me — by default you firewall off SSH, but you allow root to login? Okay, harsh lesson. Fedora is stupid. And I am stupid for not always setting a hard root password.

But it turns out, Fedora isn’t inventing the stupidity, the stupidity apperently ships with OpenSSH. Let us RTFM:


             Specifies whether root can login using ssh(1).  The argument must
             be "yes", "without-password", "forced-commands-only" or
             "no".  The default is "no".  Note that if
             ChallengeResponseAuthentication is "yes", the root user may be
             allowed in with its password even if PermitRootLogin is set to


             Specifies whether root can log in using ssh(1).  The argument
             must be "yes", "without-password", "forced-commands-only", or
             "no".  The default is "yes".


http://www.openssh.com/manual.html links to http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config:

             Specifies whether root can log in using ssh(1).  The argument
             must be "yes", "without-password", "forced-commands-only"
             or "no".  The default is "yes".

Best Practices

Read More

Categories: FreeBSD, Linux, Technical

  • Actually, about your “any user can su in linux” comment. You can lock it down to the traditional wheel group given that you’re using PAM. There’s some magic you can do in the PAM definition for the su server to change it.

  • Ah, thanks for the tip. A long time ago I chgrped su to wheel and made it 750. :)

  • The problem also comes from the fact that the username “root” is well known. Shame unix based operating systems dont tend to following the Microsoft best practice of renaming the Administrator user account (or being able to use an Administrators group).

  • Guest

    The problem is not with the design of Unix or with OpenSSH. There may be good reasons why you might want to allow root to remotely ssh into a system, especially for non-critical systems. However, nobody should allow an account to have an no password, especially privileged accounts. Nobody should leave a default account with a default password. Would you leave your front door open? Would you use a well known default combination for your safe? I am betting that most people would not, so why would one do this with access to a privileged account?

    In addition, security through obscurity is not good security. Renaming the “administrative” account is an attempt at security through obscurity. Having said that, there is nothing to stop a Unix admin from renaming the root account. It just does not do very much good, so most people don’t bother.