Non riesco ad accedere come root con il comando su, ma posso farlo con SSH

Come è possibile che non posso accedere come root su rooto su(ottengo l'errore password errata), ma posso entrare da ssh root@localhosto ssh root@my_local_IPcon la stessa password?

Sto usando CentOS 6.4.

Aggiornamento 1 :

cat /etc/pam.d/su

dà:

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

Aggiornamento2 :

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

dà:

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

ripetuto circa 20 volte.

Nel tuo commento, hai detto che /bin/suha la seguente modalità / proprietario:

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

Ci sono due problemi qui.

• deve avere il bit set-uid attivato, in modo che funzioni sempre con i permessi di root, altrimenti quando lo esegue un normale utente (non root), non avrà accesso alle informazioni sulla password /etc/shadowné la possibilità di impostare il userid per il nuovo utente desiderato.

• dovrebbe avere i bit di scrittura groupe otherdisattivati, in modo che altri utenti non possano modificarlo.

Per risolvere questo problema, accedi come root- hai detto che puoi farlo con ssh- e digita

chmod 4755 /bin/su

o, in alternativa,

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

(Il documento sugli standard per chmod fornisce maggiori dettagli sul tipo di argomenti che utilizza.) Ciò ripristinerà i bit di modalità come erano al momento della prima installazione del sistema operativo. Quando elenchi questo file, dovrebbe apparire così:

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

Come notato da @ G-Man, i file in modalità 777 potrebbero essere sovrascritti da utenti non fidati e, in tal caso, potresti volerli reinstallare dal supporto di distribuzione o dai backup.

1. gruppo ruote?

Questo è probabilmente perché il tuo useid non è nel wheelgruppo. Nelle distribuzioni Red Hat è possibile impedire esplicitamente agli utenti che non fanno parte di questo gruppo di eseguire il sucomando.

Ecco sucome appare la configurazione PAM per impostazione predefinita:

$ 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

Questa riga può limitare l'accesso al sucomando agli utenti del wheelgruppo:

auth        required    pam_wheel.so use_uid

Dal suono di ciò, questo è abilitato e il tuo userid non è autorizzato a utilizzare il sucomando.

SSH funziona dal momento che passa attraverso un diverso meccanismo PAM. SSH ha anche le proprie strutture per limitare l'accesso anche agli accessi root. Gli accessi root sono generalmente consentiti per impostazione predefinita, almeno sulla maggior parte delle distro Red Hat:

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

Anche se quanto sopra è commentato, è l'impostazione predefinita ed è come OpenSSH mostra che è l'impostazione predefinita nelle configurazioni.

Se il tuo sistema è configurato in questo modo, puoi aggiungere il tuo nome utente al wheelgruppo.

$ useradd -G wheel saml

Dopo aver effettuato il logout e il login:

$ groups
saml wheel

NOTA: mio userid è "saml" sopra.

2. Autorizzazioni proprio su su?

Verifica che l'eseguibile sia di proprietà di 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

Conferma anche che gli eseguibili hanno i loro s bit abilitati. Questo li rende setuid, in modo che quando vengono eseguiti vengono eseguiti come propri, root.

3. Cosa dicono i registri?

Quando si tenta di eseguire il su -comando, è necessario visualizzare le voci /var/log/securerelative al tentativo.

$ 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

Consulta questo registro per vedere se hai ulteriori informazioni.

4. Sei sicuro che la password non sia il problema?

Quando provo ad accedere usando su -ottengo quanto segue quando gli do una password errata:

$ su -
Password: 
su: Authentication failure
$

Proverei a creare un altro account e vedere se questo account secondario può essere eseguito su -correttamente.

Se ricevi un messaggio di errore come questo

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

Fai questo passaggio:

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

Quindi prova su. Dovrebbe funzionare.