Remote Root Login

I know one of the first things you do to secure a server is disallowing remote root login.

Passwords are pretty weak; what do people think of only allowing root login via ssh keys or other password-less methods.

Which methods are the best? Is it better just not to risk it? Is ssh-ing with a secondary account and using su - really adding any security?

How do people on serverfault.com access root on a remote server?

From serverfault Kousha

• never allow root

  set up the system to allow access via keys only no passwords

  then set up sudo for users allowed to make changes via root account

  Matt Simmons : While I agree for most situations, there are certain times that I feel alright in allowing remote root access (particularly using keys)

  drfrog : i would rather take the extra time to sudo in to do something than have root access to machine , even w a key from just a quick glance at any live server auth logs one usually sees the root login being used to try to gain access to the box, at around a 90% of all login attempts! if you have any info on a box you dont want just anyone to get access to its just in bad form to leave a box open to root
  From drfrog

• If you disable remote root access them you prevent remote attackers from directly getting root - they have to break another account, get access to the machine, and then try and get access to root. It's an extra step.

  Generally root is disabled for remote access. SU works well. If something really breaks there is always direct access to the box to fix it.

  If you want to be stricter - just disable root entirely, it's what sudo is there for. Again, with that approach you can still get root access by dropping to single-user mode - a la Ubuntu. Although, I believe they used a patched init for that, as per their docs.

  In addition you can setup idled to kick off idle users in case their terminals are left open, and PCs are open too. You can force all users to use keys, but key management can be difficult.

  A single pass-through logging host as a breakglass type system also forced an additional layer of protection and an audit trail.

  From Alex

• I suggest that you setup the system to allow root access ONLY at the console.

  Otherwise, using sudo with the password option, allow selected users access to priv'd commands. BTW, realize that sudo can be designed to restrict a user account to certain commands if you wish. Sudo, leaves a "mark" in the system log that it was used. sudo is better than su because the root password does not get disclosed. Thus you can change the root password and the user using sudo would not be any wiser.

  The allowed use of sudo to get to priv'd commands should be accompanied by forced periodic password changes with the frequency depending on the environment.

  Kousha : I feel like the problem with sudo is that it uses the user's normal password. Because of this, if the account is compromised, then root access is just a 'sudo -s' away. Using 'su' requires the attacker break two passwords.

  Kousha : Also, I will need some sort of remote root access because it's a hosted server, and I don't have access to the physical console.

  mdpc : If I recall, you can configure sudo to use the password of another account other than the users' account.
  From mdpc

• For the most part there is little gained by actually disabling remote root logins. It marginally helps enforce a policy that admins log in via their own accounts and su to root as necessary (or use sudo possibly with sudosh ... depending on your policies).

  Creating extremely long and cumbersome root passwords (effective so long as you're not still using the ancient DES+12-bit salt hashing for your passwords) is about as effective at enforcing such a policy.

  One site with which I'm familiar had a system whereby the unique passwords were randomly generated for each host, stored in a database, and pushed out to the systems. Admins were required to use ssh with their normal accounts, and sudo for most operations. However, the root password was accessible to them via an SSL based internal web service (which further required their RSA SecurID token and PIN). Fetching a root password entailed entering a justification (usually a link to a Remedy(TM) ticket number) and accesses where periodically audited. One of the few acceptable reasons for using the root password directly were in those cases where a system was stopped on fsck during the boot process ... and sulogin was requiring a real root password in order to manually run filesystem check and repair processes. (There was some discussion of alternative methods for this --- which are relatively easy for Linux, but get far more difficult as you try to extend your procedures to account for the many legacy HP-US, AIX and older SunOS and Solaris systems that were still in production in that environment).

  There are corner cases where a root password is necessary --- or at least is the best available alternative. Keeping it available while making it sufficiently robust against the sorts of threats you can anticipate is generally your best strategy.

  Another site that I know of has a rather elegant approach to decentralized account management. They have user-* and sudo-* packages (think RPMs) which are installed into the systems using the normal package management procedures and automation infrastructure. In their case the sudo-* package has a dependency on the corresponding user-* package. This is nice because it allows you to have clusters of machines with localized accounts (all accounts are admins, developers, support staff or "headless" accounts) and eliminates dependency on LDAP/NIS or other networked identity and authentication services. (This reduces the coupling among systems makes them significantly more robust).

  One think I like about that approach is that it gives flexibility. Anyone with sudo access can issue a command to add a normal user or another sudo user account. So, if I'm working on a ticket any of the people who already have access to a system can easily give me access. There's no delays while a ticket to add me to some access control list in some central database grinds through some centralized approval process and finally propagates a change back out to the system in question. Any of the authorized sudo-ers on the system can give me access and later remove me. (Yes if I were evil and they game me sudo I could maliciously modify things to retain access ... in fact there are some things I could do just as a normal user to retain access past such removal. However, that's not the threat they're worried about. My access is still limited to a relatively smaller number of systems overall; so the impact of a compromised account is still more limited than most similar schemes I've seen.

  From Jim Dennis