Remote Root Login

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-UX, 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.

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.

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.

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