I hate PAM
 

ok, I don't like PAM, it's complicated and makes no sense to me at all, but I am stuck with it on my new RHEL 5.3 x86_64 server (tried to remove it once and the whole server blew up, figuratively speaking).

What I want to do is block root from logging in via ssh, but for some reason I cannot get su to work in concert with PAM. Even at the console (mouse, keyboard and monitor connected to the physical box) I am unable to su to root from any user on the system. There are only three users other than root and they are all in the wheel group.

When I try to su to root, the message I get is:

su: incorrect password

which I know is horse puckey because I can log into root using the same password from the console, but I can't su to root from my login whether I am at the console or using PuTTY.

I have tried it with various lines in /etc/pam.d/su, such as:

auth required pam_wheel.so use_uid

auth required pam_wheel.so group=wheel (seems redundant)

auth required /lib/security/pam_wheel.so use_uid

auth required /lib64/security/pam_wheel.so use_uid (x86_64 system)


also tried the last two with the group=wheel bit too.


If I had enough hair to get a grip on, it would all be ripped out by now.

if your goal is solely to to block root ssh logins then leave PAM alone, just edit /etc/ssh/sshd_config and set PermitRootLogins to no. OR edit /etc/security/access.conf and restrict root from logging in from any remote program.

Try Slackware. It's PAM free since... uh... forever. ;)

That's really not helpful is it?

Can you be a little more clear on what you're trying to accomplish? Are you trying to prevent direct root logins over ssh? Or are you trying to prevent users from logging in over ssh and then su'ing to root?

If the former, you've already been advised on the correct sshd_config option. That's a common and effective approach.

If the latter, there's a simple PAM directive you can put into place to allow only users in the wheel group to su.

...actually there's another option using PAM involving a simple pam_listfile entry. I agree though the generic solution of modifying sshd_config should be the first thing to do.

Because the SSH option is so specific I would tend to do that for root, but with other users accounts, say you need to be a member of a certain group to log in, whilst this can be done within sshd_config I would recommend pushing it out to access.conf to make it generic.

If only one or two users log into ssh legitimately, I would add these users to an "AllowUsers" line in /etc/ssh/sshd_config. This will also disallow all other login attempts. This is easier then adding all system accounts to "DenyUsers". After I install a new distro, running ssh-keygen, configuring PublicKey ssh authentication and adding my username to AllowUsers is the first thing I do.

Thanks, I know how to disallow root via sshd_config but I wanted to keep anyone not in wheel from su to root. This will do, until I can figure out the problem between su and pam.

The following unified diff shows the change you need to make.

This would be fine if

a) I knew enough about diff's display to be certain that I understand what you meant, which appears to be "uncomment the line containing 'pam_wheel.so use_uid'"

b) I had not already tried uncommenting the line that you appear to be telling me to uncomment, in the most indirect way possible, to no avail.

What I posted is a unified diff. You'll see them commonly used to demonstrate code changes, for example. See the diff(1) manpages for more info.

In any event your assumption is correct. All you need to do is precisely what the file comment says: uncomment that line.

Then you made the change incorrectly, tested it incorrectly, or borked something else. I didn't post that to brainstorm with you; it works and I use it myself.

---

P.S. You will find that people are more inclined to help you when you're not rude and unpleasant about it. Good life lesson for you -- it applies to more than forums. ;)

Good luck.

And do you always respond to a question by telling someone to try something that they have already tried, as stated clearly in the original question?

It is this sort of techno-snobbery, and the subsequent accusations of incompetency and rudeness that invariably follow, that continues to drive people away from Linux.

The fact is, uncommenting that line did not have any effect, and I am looking for a reason why, as I have documented and reversed any other changes I have made to the server to isolate the problem. In this case, "it doesn't work", and your offensive comments don't contribute towards a solution.

I'm telling you that you "tried" it incorrectly.

Agreed, you are rude. The less attitudes we have like yours, the better. In spite of casting off a few jerks, the Linux community continues to grow. :)

Hardy har. Try re-reading this thread as an objective third party and see who is making "offensive comments". Get a grip.

Many changes can be made by editing files in /etc/security/. PAM reads these files for controlling things like secure tty's, when users can login, quotas, etc. Look in /etc/security first. Each of these files have their own manpages as well.

The reason for the wheel group is so that you can allow only wheel group members to use sudo & not have to give them the root password. The sudoers file is what controls who can use sudo, not PAM. Use the "visudo" to edit it so that errors will be detected. One gotcha is that you may need to log out before changes in sudo can take effect. Group membership changes may require this in a more general sense.

To use su, a person needs to know the root password. One protection used is to use shadow passwords. Only root can read the /etc/shadow file. Another protection is using salt. This deters the use of rainbow tables in looking up passwords given the hash. The main control over su is using a strong password and controlling access to who knows the password. The main purpose of sudo is to keep the root password secret from even other administrators, backup operators, etc.