Best of Technical Support

The first Best of Tech question in the March 2003 issue is a question that is becoming more and more common, because people and distributions are choosing higher security as a default or as an option. A possible reason that the user can't connect by SSH is the /etc/hosts.allow and /etc/hosts.deny files. Set sshd: ALL in hosts.allow, or preferably, if you know where you will SSH from, list only those hosts.

—Benjamin Judson

I am using a Seagate ST32550 SCSI hard drive with an AHA1720 interface card, but I am unable to partition it with fdisk. When I run fdisk on the drive, the changes do not become permanent, even after a reboot. The SCSI interface can detect it and can do low-level formats and verifications without a problem. When I enter fdisk, though, it creates the partition, but it does not stay put.

—Eskinder Mesfin, mesfin@attbi.com

It sounds like you are not writing the changes to the partition table; fdisk doesn't write until you tell it to write. Before you q to quit, do a w to write the changes.

—Christopher Wingert, cwingert@qualcomm.com

My modem is configured to work with the KInternet program that is activated through the KDE desktop on SuSE 8.0. The modem initializes fine, calls the server of my ISP (MSN) and then it dies. I look at the activity log and see these error messages:

Failed Authentication with peer
Possible Bad Account or Bad Password

Does MSN require a different login process than what is accommodated under KInternet?

—Chris, cgsnip@msn.com

You might want to try a different authentication scheme, such as PAP or CHAP.

—Christopher Wingert, cwingert@qualcomm.com

Some users on mailing lists report success by prepending MSN/ to the user name. So if your user name were joe, you would set the user name in KInternet to MSN/joe.

—Don Marti, dmarti@ssc.com

My SuSE 6.0 system has worked like a charm for almost five years nonstop—except for power failures—holding my DNS and Sendmail. Suddenly, the user account I always use is no longer allowed to log in. The only users that can log in are root and a second user account, but I can't figure why that user account is special. Although there's no login, I can su to any account by giving the correct password. The accounts are not locked; the passwords have not expired, the passwords are correct; the users have permissions on their home directories, and the permissions on passwd and shadow are correct. I've tried creating an account in the same group ID (admin) and groups as where the special account is listed—the one that can log in—but it didn't work. The messages in syslog are incorrect password.

—Juan Alvarez, juan.alvarez@thales-is.com

Without a closer look at your system, the gut reaction to this type of situation is to investigate the possibility of a system intrusion. Telnet sends your password in the clear over the network, and other dæmons installed on any five-year-old distribution have had vulnerability reports over the past few years. Your problem report does have that fishy smell. Barring any problems on that end, you can investigate some configuration facilities that control user logins. For example, is there an /etc/nologin file? This prevents any non-root user from logging in, and your extra user account may be given special treatment here if it is a member of the root group in /etc/group. Also, examine /etc/passwd and verify that the other users all have valid shells and home directories.

—Chad Robinson, crobinson@rfgonline.com

Given the age of the installation, you may want to upgrade to a newer and more secure distribution. A second guess would be the amount of available disk space.

—Christopher Wingert, cwingert@qualcomm.com

The two measures that prevent most security problems are 1) remove or disable unused software, which should include telnet—use OpenSSH and 2) subscribe to your distribution's security mailing list to get news of updates, then install the updates when they're available.

—Don Marti, dmarti@ssc.com