An SSH implementation should eliminate all unencrypted network logins, which will help protect the network from the
various password-sniffing vulnerabilities, as well as protect the data going back and forth across the connection.
SSH also can replace all of the r*
services on Unix servers (not that unauthenticated rlogins should be allowed anyway), as well as FTP.
The real benefit of SSH, however, is its ability to either replace services such as rdist (a utility for distributing files across systems) or allow them to tunnel through itself. For the sake of demonstration, I describe how I take a very secure system and make it the central password server. Then, from this server, I will generate custom password (and shadow) files for the other systems and distribute user accounts as required to the systems to which the users need access.
A general security rule is to have unique passwords across every system. But following this rule generally isn't
practical when you're talking about the administration of 15 or more servers. Good password selection is difficult
enough, but when a user has to create more than one and may have to change it every 30 to 90 days, the quality and the
uniqueness generally drop—dramatically.
Rather than get into a holy war over it, the administrator should assume that if he or she can't find a way to use a
one-time, token-based authentication system, users are going to need to reuse passwords across systems. It's the only
way for users to come up with decent passwords that they aren't going to write on yellow Post-It notes and place next
to their monitors. Thus, one solution is having them use different passwords across different types of systems
(front-door web servers, back-end servers, database servers, mail servers, DNS servers, SSL servers, etc.). Given
that often times these systems will be maintained by different groups of users, this often will follow existing
segmentation. Next, rdist (as well as many other services) connections can be tunneled through
SSH to distribute the password files to each of the servers. That way, administration can be done from a central
server, user accounts are placed only on systems for which access is required (to a point, this can almost be a
web-based application), and system security features such as shadowed password files are still in use. In addition,
even if the administration server dies, user access to the machines should not be interrupted because the local
password files are accurate.
However, these applications—as with all applications—have drawbacks. Constructing the proper password or authentication files for a heterogeneous environment has its difficulties. While BSDs, Linux, and Solaris variations are generally simple and very similar, HPUX and AIX variations will require a review of a number of main pages to refresh oneself with all of the fields. (Hopefully, the applications allow for the use of the Trusted Computing Base (TCB) on the HPUX servers.) This isn't the easiest way for managing user-password changes either, since changes made locally on a server will not be propagated through the rest of the environment.
Sudo: The Best Available Option
Now that the accounts are distributed across systems, let's look at Sudo. For a given environment, if someone gets enough pieces of the "root" puzzle (i.e., access to the users who can create accounts or change passwords, along with access to the users who can adjust the configuration files of the "root" distribution program), that person can acquire the equivalent of root access. So I refuse to give any credence to programs that claim to remove the "root" account. Thus, I am left with the best available option, and Sudo is a great tool in a number of ways. It is free, it has been ported to most systems, and it can be configured with a great deal of granularity.
Now, assume that I don't allow direct logins to the root account from anyplace other than the console. I'm also in an environment that has more than one administrator. (Every environment should be this way, just in case of the "hit-by-bus" scenario.) How can the functions of the root user be shared among multiple administrators while logging the actions that each user performs on the system? How do I limit who has the ability to run programs as root? How do I limit who can switch users to root?
These tasks can't all be done through system configurations on every operating system I have. However, I can add in functionality for the operations group so they can perform some of the more mundane tasks or error-checking routines on the production servers, and the administrators don't need to be called or paged with the dreaded 4 a.m. wakeup call.
With Sudo, the administrator can grant users the ability to run commands (typically as root) from an extremely granular single command or to a range as broad as any command on the system. One of its most important benefits is the increased logging. The standard practice is SU-ing to root and then executing a command or commands, where only the action of the SU may be logged. Sudo, on the other hand, logs each command and the user who ran it. It also helps prevent the occasional mistake that a user who is always logged in as root makes, like accidentally running commands or deleting files because they forget they are logged in as root.
By using the granular ability of Sudo, I can grant user-level access to users of other machine groups so that they can test connectivity between servers on the network, and I can grant users who administer those machines access to administrative commands. Access to these other accounts should be used only as a troubleshooting tool, not as a replacement for a realistic development environment. Proper testing should be taking place prior to rollouts to production.
As I alluded to earlier, Sudo is simply a tool, not an end-all, be-all security tool. If administrators get used to using it, a number of stupid mistakes will be prevented. But this won't prevent access to root or keep the server from buffer overflows. It will help administrators limit and log general system activity as well as determine who did what when they troubleshoot a system failure. And they can distribute the Sudo configuration files the same way that I distributed the password files.