Ich kann mich mit dem Befehl su nicht als root anmelden, aber mit SSH

Wie ist es möglich, dass ich mich nicht mit su rootoder als root anmelden kann su(ich erhalte einen falschen Passwortfehler), aber ich kann mich mit ssh root@localhostoder ssh root@my_local_IPmit demselben Passwort anmelden ?

Ich benutze CentOS 6.4.

Update1 :

cat /etc/pam.d/su

gibt:

#%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

Update2 :

$ sudo grep su /var/log/secure | grep -v sudo

gibt:

Feb 23 13:12:17 fallah su: pam_unix(su:auth): authentication failure;
logname=fallah uid=501 euid=501 tty=pts/0 ruser=fallah rhost=  user=root

ca. 20 mal wiederholt.

In Ihrem Kommentar haben Sie gesagt, dass /bin/suder folgende Modus / Eigentümer hat:

-rwxrwxrwx. 1 root root 30092 Jun 22 2012 /bin/su

Hier gibt es zwei Probleme.

• Das Set-UID-Bit muss aktiviert sein, damit es immer mit Root-Berechtigungen ausgeführt wird. Andernfalls hat ein normaler Benutzer (der kein Root-Benutzer ist) weder Zugriff auf die Kennwortinformationen /etc/shadownoch die Möglichkeit, die zu setzen Benutzer-ID an den gewünschten neuen Benutzer.

• Das groupund otherWrite-Bit sollte deaktiviert sein, damit andere Benutzer es nicht ändern können.

Um dies zu beheben, melden Sie sich als root- Sie sagten, Sie können dies tun mit ssh- und geben Sie ein

chmod 4755 /bin/su

oder alternativ,

chmod u+s,g-w,o-w /bin/su

(Das Standarddokument für chmod enthält nähere Informationen zu den Argumenten.) Dadurch werden die Modusbits so wiederhergestellt, wie sie bei der Erstinstallation des Betriebssystems verwendet wurden. Wenn Sie diese Datei auflisten, sollte sie so aussehen:

-rwsr-xr-x. 1 root root 30092 Jun 22 2012 /bin/su

Wie @ G-Man feststellte, können Dateien, die sich im Modus 777 befinden, von nicht vertrauenswürdigen Benutzern überschrieben werden. In diesem Fall empfiehlt es sich, sie vom Distributionsmedium oder von Sicherungen neu zu installieren.

1. Radgruppe?

Dies liegt wahrscheinlich daran, dass sich Ihre useid nicht in der wheelGruppe befindet. In Red Hat-Distributionen können Sie Benutzern, die nicht zu dieser Gruppe gehören, die Ausführung des suBefehls explizit untersagen .

So susieht die PAM-Konfiguration standardmäßig aus:

$ more /etc/pam.d/su
#%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

Diese Zeile kann den Zugriff auf den suBefehl auf Benutzer in der wheelGruppe beschränken:

auth        required    pam_wheel.so use_uid

Nach dem Geräusch ist dies aktiviert und Ihre Benutzer-ID darf den suBefehl nicht ausführen .

SSH funktioniert, da es einen anderen PAM-Mechanismus durchläuft. SSH hat auch eigene Möglichkeiten, um den Zugriff auf Root-Logins zu beschränken. Root-Anmeldungen sind in der Regel standardmäßig zulässig, zumindest in den meisten Red Hat-Distributionen:

$ sudo grep PermitRoot /etc/ssh/sshd_config 
#PermitRootLogin yes
# the setting of "PermitRootLogin without-password".

Obwohl das Obige auskommentiert ist, ist es die Standardeinstellung und zeigt, wie OpenSSH die Standardeinstellung in den Konfigurationen ist.

Wenn Ihr System so konfiguriert ist, können Sie der wheelGruppe Ihren Benutzernamen hinzufügen .

$ useradd -G wheel saml

Nach dem Abmelden und erneuten Anmelden:

$ groups
saml wheel

HINWEIS: Meine Benutzer-ID lautet oben "saml".

2. Berechtigungen direkt am su?

Überprüfen Sie, ob die ausführbare Datei im Besitz von root ist.

$ type -a su
su is /usr/bin/su
su is /bin/su

$ ls -l /usr/bin/su /bin/su
-rwsr-xr-x. 1 root root 32064 Jan 13 06:31 /bin/su
-rwsr-xr-x. 1 root root 32064 Jan 13 06:31 /usr/bin/su

Stellen Sie außerdem sicher, dass die sBits der ausführbaren Dateien aktiviert sind. Das macht sie zu setuid, so dass sie, wenn sie ausgeführt werden, als ihre eigene root laufen.

3. Was sagen die Protokolle?

Wenn Sie versuchen, den su -Befehl auszuführen, sollten Sie Einträge /var/log/secureüber den Versuch sehen.

$ sudo grep su /var/log/secure | grep -v sudo
Feb 23 23:31:26 greeneggs su: pam_unix(su-l:session): session opened for user root by saml(uid=0)
Feb 24 00:27:32 greeneggs su: pam_unix(su-l:session): session closed for user root
Feb 24 01:34:12 greeneggs su: pam_unix(su-l:session): session opened for user root by saml(uid=1000)
Feb 24 01:34:26 greeneggs su: pam_unix(su-l:session): session closed for user root

Sehen Sie in diesem Protokoll nach, ob Sie zusätzliche Informationen erhalten.

4. Sind Sie sicher, dass das Passwort nicht das Problem ist?

Wenn ich versuche, mich mit anzumelden, su -erhalte ich Folgendes, wenn ich ein falsches Passwort eingebe:

$ su -
Password: 
su: Authentication failure
$

Ich würde versuchen, ein anderes Konto zu erstellen und zu prüfen, ob dieses sekundäre Konto su -erfolgreich ausgeführt werden kann.

Wenn Sie eine solche Fehlermeldung erhalten

su: PAM adding faulty module: /lib64/security/pam_tally.so
su: PAM unable to dlopen(/lib64/security/pam_tally.so): /lib64/security/pam_tally.so: cannot open shared object file: No such file or directory

Mach diesen Schritt:

ln -s /lib64/security/pam_tally2.so /lib64/security/pam_tally.so

Dann versuche es mit su. Es sollte funktionieren.