Não consigo fazer login como root com o comando su, mas consigo com o SSH

Como é possível não conseguir fazer login como root por ( su rootou surecebo erro de senha incorreto), mas consigo fazer login com ssh root@localhostou ssh root@my_local_IPcom a mesma senha?

Estou usando o CentOS 6.4.

Update1 :

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

Update2 :

$ 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

repetido cerca de 20 vezes.

No seu comentário, você disse que /bin/supossui o seguinte modo / proprietário:

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

Existem dois problemas aqui.

• ele precisa ter o bit set-uid ativado, para que ele sempre seja executado com permissões de root; caso contrário, quando um usuário comum (não root) o executar, ele não terá acesso às informações da senha /etc/shadownem a capacidade de definir o ID do usuário para o novo usuário desejado.

• ele deve ter os bits de gravação groupe otherdesativados, para que outros usuários não possam alterá-lo.

Para corrigir isso, faça o login como root- você disse que pode fazer isso com ssh- e digite

chmod 4755 /bin/su

ou alternativamente,

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

(O documento de padrões do chmod entra em mais detalhes sobre que tipos de argumentos são necessários.) Isso restaurará os bits de modo da maneira que eram quando o sistema operacional foi instalado pela primeira vez. Quando você lista este arquivo, ele deve ficar assim:

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

Como o @ G-Man observou, os arquivos no modo 777 podem ser substituídos por usuários não confiáveis ​​e, se for o caso, convém reinstalá-los a partir da mídia de distribuição ou de backups.

1. grupo de rodas?

Provavelmente, porque o seu ID de uso não está no wheelgrupo. Nas distros do Red Hat, você pode impedir explicitamente que os usuários que não estão neste grupo executem o sucomando.

Aqui está a suaparência da configuração do PAM por padrão:

$ 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

Esta linha pode limitar o acesso ao sucomando aos usuários no wheelgrupo:

auth        required    pam_wheel.so use_uid

Pelo que parece, isso está ativado e seu ID do usuário não tem permissão para operar o sucomando.

O SSH funciona, pois passa por um mecanismo PAM diferente. O SSH também possui suas próprias instalações para limitar o acesso a logins raiz também. Logins raiz geralmente são permitidos por padrão, pelo menos na maioria das distribuições da Red Hat:

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

Mesmo que o acima seja comentado, é o padrão e é como o OpenSSH mostra que é a configuração padrão nas configurações.

Se seu sistema estiver configurado assim, você poderá adicionar seu nome de usuário ao wheelgrupo.

$ useradd -G wheel saml

Depois de sair e entrar novamente:

$ groups
saml wheel

NOTA: Meu ID do usuário é "saml" acima.

2. Permissões certas no su?

Verifique se o executável pertence à raiz.

$ 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

Confirme também que os executáveis ​​têm seus sbits ativados. Isso os torna setuid, para que, quando executados, executem como seus próprios, root.

3. O que os logs dizem?

Ao tentar executar o su -comando, você verá entradas /var/log/securesobre a tentativa.

$ 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

Consulte este log para ver se você obtém informações adicionais.

4. Você tem certeza de que a senha não é o problema?

Quando tento fazer login usando su -, recebo o seguinte quando atribuo uma senha incorreta:

$ su -
Password: 
su: Authentication failure
$

Eu tentaria criar outra conta e ver se essa conta secundária pode ser executada com su -êxito.

Se você estiver recebendo uma mensagem de erro como esta

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

Faça este passo:

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

Então tente su. Deveria funcionar.