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

Question

Como é possível que eu não possa fazer login como root por su root ou su (recebo um erro de senha incorreto), mas posso fazer login por ssh root@localhost ou ssh root@my_local_IP com 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.

    

Answer 1

Em seu comentário, você disse que /bin/su tem 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 de senha em /etc/shadow nem a capacidade de definir o ID do usuário para o novo usuário desejado.

• ele deve ter os bits de gravação group e other desativados, 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 padrão para o chmod entra em mais detalhes sobre quais tipos de argumentos são necessários .) Isso restaurará os bits de modo da maneira que estavam 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 que são do modo 777 podem ser substituídos por usuários não confiáveis e, se esse for o caso, você pode querer reinstalá-los a partir do meio de distribuição ou backups.

    

Answer 2

1. grupo de rodas?

Isso é provável porque o seu ID de uso não está no grupo wheel . Nas distribuições da Red Hat você pode explicitamente proibir os usuários que não estão neste grupo de executar o comando su .

Veja como é a configuração su 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 comando su aos usuários no grupo wheel :

auth        required    pam_wheel.so use_uid

Pelo som, isso está habilitado e seu ID de usuário não tem permissão para operar o comando su .

O SSH funciona desde que passa por um mecanismo PAM diferente. O SSH também possui instalações próprias para limitar o acesso a logins raiz também. Os logins de raiz são normalmente 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.

Trabalhando com isso?

Se o seu sistema estiver configurado dessa maneira, você poderá adicionar seu nome de usuário ao grupo wheel .

$ useradd -G wheel saml

Depois de sair e voltar a entrar:

$ groups
saml wheel

OBSERVAÇÃO: Meu ID do usuário é "saml" acima.

2. Permissões à direita na su?

Verifique se o executável é de propriedade do 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

Confirme também se os executáveis têm seus s bits habilitados. Isso os torna setuid, de modo que, quando são executados, eles são executados como root.

3. O que dizem os registros?

Quando você tentar fazer o comando su - , deverá ver as entradas em /var/log/secure sobre 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 registro para ver se você recebe informações adicionais.

4. Tem certeza de que a senha não é o problema?

Quando tento fazer o login usando su - , obtenho o seguinte quando forneço uma senha incorreta:

$ su -
Password: 
su: Authentication failure
$

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

    

Answer 3

Se você está 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. Deve funcionar.