Я не могу войти как root с помощью команды su, но я могу с SSH

Как это возможно, что я не могу войти в систему как пользователь root su rootили su(я получаю ошибку неверного пароля), но я могу войти в систему ssh root@localhostили ssh root@my_local_IPс тем же паролем?

Я использую CentOS 6.4.

Обновление 1 :

cat /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

Обновление 2 :

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

дает:

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

повторил около 20 раз.

В своем комментарии вы сказали, что /bin/suимеет следующий режим / владельца:

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

Здесь есть две проблемы.

• ему нужно включить бит set-uid, чтобы он всегда работал с правами root, иначе, когда его запускает обычный (не root) пользователь, он не будет иметь доступа ни к информации о пароле, /etc/shadowни к возможности установить ID пользователя для нового пользователя.

• он должен иметь отключенные биты записи groupи otherзаписи, чтобы другие пользователи не могли его изменить.

Чтобы это исправить, войдите как root- вы сказали, что можете сделать это с ssh- и введите

chmod 4755 /bin/su

или, альтернативно,

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

(В документе стандартов для chmod более подробно рассказывается о том, какие аргументы он принимает.) Это восстановит биты режима такими же, какими они были при первоначальной установке операционной системы. Когда вы перечисляете этот файл, он должен выглядеть так:

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

Как заметил @ G-Man, файлы в режиме 777 могут быть перезаписаны ненадежными пользователями, и в этом случае вы можете переустановить их с носителя или резервных копий.

1. колесная группа?

Вероятно, это потому, что ваш useid отсутствует в wheelгруппе. В дистрибутивах Red Hat вы можете явно запретить пользователям запускать suкоманду пользователям, не входящим в эту группу .

Вот как suвыглядит конфигурация 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

Эта строка может ограничить доступ к suкоманде для пользователей в wheelгруппе:

auth        required    pam_wheel.so use_uid

Судя по всему, это включено, и ваш ID пользователя не может управлять suкомандой.

SSH работает, так как проходит через другой механизм PAM. SSH также имеет свои собственные средства для ограничения доступа к корневым учетным записям. Вход в систему root обычно разрешен по умолчанию, по крайней мере в большинстве дистрибутивов Red Hat:

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

Несмотря на то, что вышеприведенное закомментировано, это значение по умолчанию, и именно так OpenSSH показывает, что это значение по умолчанию в конфигах.

Если ваша система настроена так, вы можете добавить свое имя пользователя в wheelгруппу.

$ useradd -G wheel saml

После выхода из системы и обратно:

$ groups
saml wheel

ПРИМЕЧАНИЕ. Мой идентификатор пользователя - "saml" выше.

2. Разрешения права на су?

Убедитесь, что исполняемый файл принадлежит 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

Также убедитесь, что исполняемые файлы имеют свои sбиты включены. Это делает их setuid, так что когда они выполняются, они запускаются как свои собственные, root.

3. Что говорят логи?

Когда вы попытаетесь выполнить su -команду, вы должны увидеть записи /var/log/secureо попытке.

$ 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

Обратитесь к этому журналу, чтобы увидеть, если вы получите дополнительную информацию.

4. Вы уверены, что пароль не проблема?

Когда я пытаюсь войти в систему, используя su -неправильный пароль, я получаю следующее:

$ su -
Password: 
su: Authentication failure
$

Я бы попытался создать другую учетную запись и посмотреть, может ли эта дополнительная учетная запись работать su -успешно.

Если вы получаете сообщение об ошибке, подобное этому

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

Сделайте этот шаг:

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

Тогда попробуйте su. Он должен работать.