Я не можу увійти як 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а також не зможе встановити параметр userid потрібному новому користувачеві.

• Потрібно вимкнути біти запису 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

З цього звуку це ввімкнено, а користувачеві не дозволяється керувати suкомандою.

SSH працює, оскільки він проходить через інший механізм PAM. SSH також має власні засоби для обмеження доступу до кореневих логінів. Кореневі входи, як правило, дозволені за замовчуванням, принаймні, у більшості дистрибутивів 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

ПРИМІТКА. Мій userid - "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файлах увімкнено їх біти. Це робить їх налаштованими, так що після їх виконання вони працюють як власний, 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

Потім спробуйте су. Це має працювати.