Je ne peux pas me connecter en tant que root avec la commande su, mais je peux le faire avec SSH

17

Comment est-il possible que je ne puisse pas me connecter en tant que root par su rootou su(j'obtiens une erreur de mot de passe incorrect), mais que je peux me connecter par ssh root@localhostou ssh root@my_local_IPavec le même mot de passe?

J'utilise CentOS 6.4.


Update1 :

cat /etc/pam.d/su

donne:

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

donne:

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

répété environ 20 fois.

Alireza Fallah
la source
1
Essayez d'effacer le fichier /etc/securetty( cp /etc/securetty{,.old}; : > /etc/securetty). Si cela ne fonctionne toujours pas, fournissez le contenu de /etc/pam.d/su.
Patrick
2
ssh 192.168.1.218Vous vous connectez sûrement avec vous-même? Pour vous connecter en tant que root via, vous sshauriez normalement besoin de ssh [email protected]ou ssh root@localhost.
Graeme
1
Obtenez le PID (12345) de votre shell ( echo $$), ouvrez (par exemple via ssh) un shell racine (nécessaire pour tracer les binaires SUID) et démarrez stracepour ce shell: strace -o su.strace -p 12345 -fet recherchez des erreurs étranges avant le message d'erreur. Ou copiez les 30 dernières lignes avant le message d'erreur dans votre question si vous n'êtes pas familier avec ce type de sortie.
Hauke ​​Laging
1
@HaukeLaging ça ditProcess 11736 attached - interrupt to quit
Alireza Fallah
2
OK, c'est la raison pour laquelle cela ne fonctionne pas. / bin / su doit avoir son bit setuid activé pour que lorsque les utilisateurs ordinaires (non root) l'utilisent, il aura accès à la liste des mots de passe dans / etc / shadow. Tapez, en tant que root, chmod 4755 /bin/supour résoudre ce problème.
Mark Plotnick

Réponses:

23

Dans votre commentaire, vous avez dit qu'il /bin/sua le mode / propriétaire suivant:

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

Ici, nous avons deux problèmes.

  • il doit avoir le bit set-uid activé, afin qu'il s'exécute toujours avec les autorisations root, sinon, lorsqu'un utilisateur ordinaire (non root) l'exécute, il n'aura pas accès aux informations de mot de passe /etc/shadowni à la possibilité de définir le id_utilisateur au nouvel utilisateur souhaité.

  • il devrait avoir les bits d'écriture groupet otherdésactivés, afin que les autres utilisateurs ne puissent pas les modifier.

Pour résoudre ce problème, connectez root-vous en - vous avez dit que vous pouvez le faire avec ssh- et tapez

chmod 4755 /bin/su

Ou bien,

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

(Le document sur les normes de chmod donne plus de détails sur les types d'arguments qu'il prend.) Cela restaurera les bits de mode tels qu'ils étaient lors de la première installation du système d'exploitation. Lorsque vous répertoriez ce fichier, il devrait ressembler à ceci:

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

Comme l'a noté @ G-Man, les fichiers en mode 777 peuvent être remplacés par des utilisateurs non fiables, et si tel est le cas, vous pouvez les réinstaller à partir du support de distribution ou des sauvegardes.

Mark Plotnick
la source
1
J'utilise habituellement comme:, à chmod 755 /bin/suquoi servent les 4 supplémentaires ?
Alireza Fallah
Le 4dans la première position représente l'autorisation set-uid. J'ai modifié ma réponse pour ajouter une autre façon d'utiliser chmod en utilisant des noms symboliques pour les bits d'autorisation. Espérons que ce sera plus clair.
Mark Plotnick
Merci beaucoup. J'ai maintenant compris que j'avais exécuté le chmod -R 777 /binpar erreur, et c'est pourquoi j'ai été maudit: D
Alireza Fallah
J'ai aussi posé une autre question , voulez-vous la voir, vous connaissez peut-être la réponse.
Alireza Fallah
cyberciti.biz/tips/… décrit comment utiliser rpmpour restaurer les autorisations de fichier, mais je ne l'ai pas essayé.
Mark Plotnick
10

1. groupe de roues?

Cela est probablement dû au fait que votre ID utilisateur ne fait pas partie du wheelgroupe. Sur les distributions Red Hat, vous pouvez explicitement interdire aux utilisateurs qui ne font pas partie de ce groupe d'exécuter la sucommande.

Voici à quoi suressemble la configuration PAM par défaut:

$ 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

Cette ligne peut limiter l'accès à la sucommande aux utilisateurs du wheelgroupe:

auth        required    pam_wheel.so use_uid

D'après le son, cela est activé et votre ID utilisateur n'est pas autorisé à exécuter la sucommande.

SSH fonctionne car il passe par un mécanisme PAM différent. SSH dispose également de ses propres installations pour limiter l'accès aux connexions root également. Les connexions root sont généralement autorisées par défaut, au moins sur la plupart des distributions Red Hat:

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

Même si ce qui précède est commenté, c'est la valeur par défaut, et c'est ainsi qu'OpenSSH montre que c'est le paramètre par défaut dans les configurations.

Travailler avec ça?

Si votre système est configuré comme ceci, vous pouvez ajouter votre nom d'utilisateur au wheelgroupe.

$ useradd -G wheel saml

Après vous être déconnecté et reconnecté:

$ groups
saml wheel

REMARQUE: mon ID utilisateur est "saml" ci-dessus.

2. Autorisations à droite sur su?

Vérifiez que l'exécutable appartient à 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

Vérifiez également que les exécutables ont leurs sbits activés. Cela les rend setuid, de sorte que lorsqu'ils sont exécutés, ils s'exécutent en tant que root.

3. Que disent les journaux?

Lorsque vous tentez d'exécuter la su -commande, vous devriez voir des entrées à /var/log/securepropos de la tentative.

$ 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

Consultez ce journal pour voir si vous obtenez des informations supplémentaires.

4. Êtes-vous sûr que le mot de passe n'est pas le problème?

Lorsque j'essaie de me connecter avec, su -j'obtiens ce qui suit lorsque je lui donne un mot de passe incorrect:

$ su -
Password: 
su: Authentication failure
$

J'essaierais de créer un autre compte et de voir si ce compte secondaire peut fonctionner su -correctement.

slm
la source
je vous remercie par votre excellente réponse, ce que j'ai essayé après avoir lu votre réponse:, usermod -a -G wheel my_usernameet le résultat de groupsest fallah wheel. Donc le résultat de cat /etc/pam.d/suest maintenant dans ma question, ET, encore une fois, je ne peux pas me connecter en tant que root par la commande su !!!
Alireza Fallah
c'est la dernière ligne de /var/log/secure:Feb 24 10:19:45 fallah su: pam_unix(su:auth): authentication failure; logname=fallah uid=501 euid=501 tty=pts/2 ruser=fallah rhost= user=root
Alireza Fallah
et cette ligne est répétée environ 20 fois dans/var/log/secure
Alireza Fallah
4: mais quand j'essaye: su: incorrect password - et le mot de passe est correct, car je peux me connecter avec le même mot de passe dans SSH
Alireza Fallah
J'ai également essayé de me connecter avec un autre compte, comme su alireza, et encore le même problème
Alireza Fallah
0

Si vous obtenez un message d'erreur comme celui-ci

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

Effectuez cette étape:

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

Essayez ensuite su. Ça devrait marcher.

Jeff Schaller
la source