Hi Norman, I can't say much about the /etc/issue file since I've never really dealt with it. If you figure out what do about the issue file, could you please let me know, too. By the way, this is the first time I've ever noticed a /etc/issue.net file. Is this new to hamm, or was it in bo, too?
Anyway, what I've done on some of our systems is the following: - Disable all insecure incoming connections in /etc/inetd.conf or xinetd.conf, whichever you are using: - shell, login, exec - (rsh, rlogin, rexec) - finger, tftp, bootps, rusersd, telnet, ftp I'm sure there are others but these were the ones that stood out the most. Of course, all outgoing connections would still work, such as rlogins and telnets. I tend to prefer ssh over ssltelnet. IMHO, it provides better security. Forcing connections via Secure Shell is preferrable but not always possible since some of our users can't always use a machine that has the ssh clients installed when they are "away." The same goes for ssltelnet. To my understanding, ssltelnet only works securely if both sides are using ssltelnet/d. Why bother trying to provide an encrypting telnet if the machine they are using doesn't provide an encrypting telnet or if they are just going to type their password over the clear during an ftp session (unless you are using sslftp). In such cases, we've provided them with one time passwords (OTPs), meaning that we would have to reenable telnetd and ftpd in inetd.conf. Using OTPs allows a user to type a password as clear text over the net without worrying about password sniffers since the password would only be used once. The next time the user logs in, he/she would enter the OTP next on the list. This is great, although slightly tedious at first since the OTPs tend to be long. No big deal if you take into account it is more secure then standard telnets. A pretty good OTP package that I've used is called OPIE. OPIE provides OTP replacements for in.logind (for incoming telnets), in.ftpd and su (for more secure su-ing). There is a Debian package for it, although it is slightly outdated, last time I checked. In general, we try to use a combination of Secure Shell and one time passwords (for those w/o access to ssh clients). It doesn't seem possible to get 100% security, but the above steps should make things a bit more secure. Sorry if you already knew all of this. -Ossama -- E-mail the word "unsubscribe" to [EMAIL PROTECTED] TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to [EMAIL PROTECTED] .