UNIX System Administration Handbook - Evi Nemeth [399]
• Method D:Finally, sshd can simply allow the user to enter his or her normal login password. This makes ssh behave very much like telnet, except that the password and session are both encrypted. The main drawbacks of this method are that system login passwords are relatively weak (often limited to 8 significant characters) and that there are ready-made tools (like crack) designed to break them. However, this method is probably the best choice for normal use.
Authentication policy is set in the /etc/sshd_config file. You will see at once that this file has been filled up with configuration garbage for you, but most of it can be safely ignored. The options relevant to authentication are shown in Table 21.1.
Table 21.1 Authentication-related options in /etc/sshd_config
a. The authentication methods to which this variable is relevant.
b. But continues to honor ~/.shosts and shosts.equiv.
c. Defaults to the value of IgnoreRhosts.
Our suggested configuration, which allows methods C and D but not methods A or B, is as follows.
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
PasswordAuthentication yes
SRP: Secure Remote Password
The SRP protocol from Thomas Wu at Stanford provides a simple, fast, exportable, patent-free, and highly secure way to verify passwords over a public network. SRP has been less widely adopted than SSH, but it appears to be a more elegant protocol. The software is administratively simpler, and the protocol is easier to adapt to existing services. Rather than switching over to a new set of commands, as SSH requires, users can continue to use telnet and ftp in the same way they always did. The only difference is that network communications will now be transparently secured. In the specific cases of telnet and ftp, the SRP-ized clients and servers are backward compatible with their standard counterparts. Secure authentication and encryption are used only when both parties support it.
Unfortunately, the standard DES encryption used by UNIX does not have the mathematical properties necessary to support SRP, and user passwords for SRP must therefore be stored outside the /etc/passwd file. The current SRP package (available on the web from srp.stanford.edu) defines a sort of shadow password file, /etc/tpasswd, that contains the SRP version of each user’s password. A replacement for the standard passwd command keeps the passwords in both files synchronized.
OPIE: One-time Passwords in Everything
One of the problems with systems such as SSH and SRP is that both ends of a connection must support a special protocol to secure the connection. This is normally not a problem, but users can sometimes find themselves stranded. SSH clients are not available for all operating systems, and users may occasionally want to log in through other people’s computers when on the road.
The one-time password (OTP) standard defined in RFC1938 takes a somewhat different approach to password security: instead of encrypting passwords, you just make sure that they only work once. Plaintext passwords can then be entered over the net with impunity, since it does not matter if anyone overhears them. Users typically print out a series of one-time passwords to carry around with them. Unlike regular passwords, one-time passwords are generated on your behalf; you don’t get to select them.
OPIE is the most commonly used OTP system today. It’s an offshoot of an earlier system called S/Key from Bellcore (now Telcordia Technologies) that was further developed at the U.S. Naval Research Laboratories. OPIE’s main features are OTP-compatible versions of telnetd and ftpd and utilities for generating and administering password lists. It’s available from www.inner.net/pub/opie.
It’s important to note that OTP systems address only the issue of password snooping. They cannot and do not encrypt the actual content of a conversation. Someone listening in on your telnet session might not be able to obtain a usable password, but they could certainly