Unable to access root over SSH after PermitRootLogin is set to no

[holodoc]

Hello there.

I followed the instructions on this page ([http: // wiki.centos.org/HowTos/Network/SecuringSSH]) in order to secure my sshd and prevent anyone form accessing the server directly as root. Therefore I changed the "PermitRootLogin yes" to "PermitRootLogin no" and restarted sshd. After that root access was denied directly but for some reason I am unable to switch to root from any of the normal user accounts with "su -" because I keep getting the "Incorrect password" errors. I am sure that the password is correct but for some, to me unclear, reasons I am unable to access the root account over SSH from a normal user account. I also noticed that after that I lost the ability to access the server as root over SFTP.

Can anyone shed some light on why I am unable to generally use the root account after doing the named changes to sshd_config/ I am running CentOS 5.4 with the newest update. Thank you.

[scathefire]

as far as sftp goes it still behaves in accordance to whatever your ssh configs are set to. so you say no root login, that goes for sftp too.

so what you are saying is after you ssh in and run your command to become root (su -) and type in root's password it will not let you become root? that is odd, perhaps you should try setting up sudo and see if it fails as well.

[holodoc]

so what you are saying is after you ssh in and run your command to become root (su -) and type in root's password it will not let you become root? that is odd, perhaps you should try setting up sudo and see if it fails as well.

Exactly. Its seems rather odd that I am able to login as any other user except root. I also can't find anywhere reports of a similar behavior which is also kind of hard to believe.

As for the sudo part I don't like sudo Yeah I know a lot of people will now comment about how sudo is awesome and has great features but I personally have never found it to be superior to one root account on machines that are going to be maintained by not more than one or two people which is the case here.

Anyway thanks for your input scathefire. If anyone has any further proposals I am all ears because I can be pretty stubborn when it comes to chasing Linux ghosts like this

[scathefire]

maybe its a PAM issue. what does /etc/pam.d/su look like?

[holodoc]

maybe its a PAM issue. what does /etc/pam.d/su look like?

Unfortunately as I already said I am unable to access the computer right now since its located in a laboratory about hundred miles away from my current location However I don't think that its PAM related because in that case I would most certainly have problems with all the rest of the users. Either way I am still going to investigate the whole thing as soon as someone from the administration team on the other side decided to allow root access again for me

[scathefire]

the only reason i suggested PAM is part because of this:

Can't su into root as normal user - LinuxQuestions.org

besides, you should still be able to read the pam module, just not modify it.

[holodoc]

Anytime I'm about to chop down the tree I've climbed, I usually login a second time as a backup precaution, then I can test what I'm doing before it's too late.

I know hindsight is 20:20 and it's easy to be a sage at this point but it had to be mentioned.

Sudo would be my suggestion if you still had a way to root into it. Are you sure you can't think of any other ways in?

I tried everything I could think of but as I already said its not such a big deal about me not able to log in now but why I am unable to su to root from accounts I am able to log in from SSH As for the tree chopping part I know but this time nothing suggested that there is going to be problems with switching to root since I tried to log in as normal user from another ssh session and it worked. The surprise was full when I figured out that I was not able to switch to root from a new session and the old one was closed previously.

the only reason i suggested PAM is part because of
besides, you should still be able to read the pam module, just not modify it.

Thanks for the link. As for the /etc/pam.d/su here is the contents although I can't seem to finf anything wrong.

#%PAM-1.0
auth            sufficient      pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth           sufficient      pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth           required        pam_wheel.so use_uid
auth            include         system-auth
account         sufficient      pam_succeed_if.so uid = 0 use_uid quiet
account         include         system-auth
password        include         system-auth
session         include         system-auth
session         optional        pam_xauth.so

[scathefire]

another place to check is the /etc/security. sometimes there are settings in there, maybe access.conf that can control who logs in and such.

did you say you logged in as another user and it worked, or did i misread that? if there is another account that it works for, perhaps it would be wise to check out what is so special about it (what group(s) it belongs to, etc.)

be sure to check out /etc/group as well

[holodoc]

did you say you logged in as another user and it worked, or did i misread that? if there is another account that it works for, perhaps it would be wise to check out what is so special about it (what group(s) it belongs to, etc.)

Yes I did The problem appeared right after I changed the above setting (PermitRootLogin yes) to (PermitRootLogin no).

My intention was to disable direct root login through SSH (which actually works too good ) and to allow unprivileged members to switch to root with su only after they have logged as regular users through SSH.

The end result was that everyone else (unprivileged users) can login but after I try to switch to root with "su -" I get the Incorrect password response