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.