Nie mogę zalogować się jako root za pomocą polecenia su, ale mogę za pomocą SSH

Jak to możliwe, że nie mogę zalogować się jako root przez su rootlub su(mam nieprawidłowe błąd hasło), ale mogę się zalogować przez ssh root@localhostlub ssh root@my_local_IPz tego samego hasła?

Używam CentOS 6.4.

Aktualizacja 1 :

cat /etc/pam.d/su

daje:

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

Aktualizacja 2 :

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

daje:

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

powtórzone około 20 razy.

W swoim komentarzu powiedziałeś, że /bin/suma następujący tryb / właściciela:

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

Są tutaj dwa problemy.

• musi mieć włączony bit set-uid, aby zawsze działał z uprawnieniami administratora, w przeciwnym razie, gdy uruchomi go zwykły użytkownik (inny niż root), nie będzie miał dostępu do informacji o haśle /etc/shadowani możliwości ustawienia identyfikator użytkownika dla pożądanego nowego użytkownika.

• powinien mieć wyłączone bity zapisu groupi otherzapisu, aby inni użytkownicy nie mogli go zmienić.

Aby to naprawić, zaloguj się jako root- powiedziałeś, że możesz to zrobić ssh- i wpisz

chmod 4755 /bin/su

lub alternatywnie

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

(Dokument standardu dla chmod zawiera bardziej szczegółowe informacje na temat tego, jakie argumenty przyjmuje.) To przywróci bity trybu do stanu, w jakim były podczas pierwszej instalacji systemu operacyjnego. Kiedy wyświetlasz ten plik, powinien on wyglądać następująco:

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

Jak zauważył @ G-Man, pliki w trybie 777 mogą zostać zastąpione przez niezaufanych użytkowników, a jeśli tak, to możesz chcieć je ponownie zainstalować z nośnika dystrybucyjnego lub kopii zapasowych.

1. grupa kół?

Jest to prawdopodobne, ponieważ Twój identyfikator użytkownika nie znajduje się w wheelgrupie. W dystrybucjach Red Hat możesz jawnie zabronić użytkownikom, którzy nie są w tej grupie, uruchamiania sukomendy.

Oto sujak domyślnie wygląda konfiguracja PAM:

$ 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

Ta linia może ograniczyć dostęp do supolecenia do użytkowników w wheelgrupie:

auth        required    pam_wheel.so use_uid

Z tego dźwięku jest to włączone, a twój identyfikator użytkownika nie może obsługiwać supolecenia.

SSH działa, ponieważ przechodzi przez inny mechanizm PAM. SSH ma również własne możliwości ograniczania dostępu do loginów root. Logowanie do rootowania jest zazwyczaj domyślnie dozwolone, przynajmniej w większości dystrybucji Red Hat:

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

Mimo, że powyższe zostało skomentowane, jest to ustawienie domyślne i pokazuje, jak OpenSSH pokazuje, że jest to ustawienie domyślne w konfiguracjach.

Jeśli Twój system jest skonfigurowany w ten sposób, możesz dodać swoją nazwę użytkownika do wheelgrupy.

$ useradd -G wheel saml

Po wylogowaniu i ponownym zalogowaniu:

$ groups
saml wheel

UWAGA: Mój identyfikator użytkownika to „saml” powyżej.

2. Uprawnienia na su?

Sprawdź, czy plik wykonywalny jest własnością użytkownika root.

$ 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

Potwierdź również, że pliki wykonywalne mają swłączone bity. To sprawia, że ​​są setuidami, więc kiedy są wykonywane, uruchamiają się jako root.

3. Co mówią logi?

Podczas próby wykonania su -polecenia powinieneś zobaczyć wpisy /var/log/securedotyczące tej próby.

$ 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

Przejrzyj ten dziennik, aby uzyskać dodatkowe informacje.

4. Czy na pewno hasło nie stanowi problemu?

Podczas próby zalogowania się przy użyciu su -niepoprawnego hasła otrzymuję następujące informacje:

$ su -
Password: 
su: Authentication failure
$

Spróbuję utworzyć kolejne konto i sprawdzić, czy to drugie konto może działać su -poprawnie.

Jeśli pojawia się taki komunikat o błędzie

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

Wykonaj ten krok:

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

Następnie spróbuj su. To powinno działać.