Странное изменение в поведении ssh + LDAP

Question

Странное изменение в поведении ssh + LDAP

У нас есть кластер с передним узлом, который допускает обычных пользователей и пользователей LDAP. Два дня назад ssh показывает странное поведение:

Пользователи LDAP не могут войти на передний узел, используя пароль
но пользователи LDAP могут войти, если они установят ssh-ключ в авторизованных ключах
обычные пользователи (без LDAP, /etc/passwd) могут войти без проблем
Другие сервисы, использующие тот же сервер LDAP, работают правильно

Итак, я думаю, что проблема находится в переднем узле. LDAP, кажется, работает, используя getent [passwd|shadow] Команда мы получаем всех пользователей.

В то же время, ssh показывает предупреждение / ошибку, когда мы входим из этого узла в другие узлы. Но это все равно позволяет ssh:

[root@frontnode ~]# ssh othernode
/etc/ssh/ssh_config line 50: Unsupported option "GSSAPIAuthentication"
[root@othernode ~]#

Также, когда я перезапускаю демон ssh, у нас также появляются ошибки, связанные с GSSAPI:

[root@frontnode ~]# service sshd restart
Stopping sshd:                                             [  OK  ]
Starting sshd: /etc/ssh/sshd_config line 81: Unsupported option GSSAPIAuthentication
/etc/ssh/sshd_config line 83: Unsupported option GSSAPICleanupCredentials
/etc/ssh/sshd_config line 97: Unsupported option UsePAM
                                                           [  OK  ]

Никто не изменил ни конфигурацию ssh, ни конфигурацию sshd. И работал до сих пор. Мы не знаем, в чем проблема.

Узел входа в систему представляет собой Scientific Linux Release 6.2 (на основе Redhat).

0

ssh ldap pam gssapi

Источник

Zhen 21 авг '13 в 10:29

1 ответ

Другие вопросы по тегам ssh ldap pam gssapi

Jeff Strunk 21 авг '13 в 15:19 2013-08-21 15:19 · Answer 1 · 2013-08-21 15:19

Похоже, что sshd или некоторые библиотеки были изменены на переднем узле.

UsePAMОпция - это то, что позволит вам войти с паролями, хранящимися в LDAP.

Шаги по устранению неполадок

Вы должны проверить свой /var/log/yum.log для любых изменений пакета.
У вас там работает система управления конфигурацией? Убедитесь, что никто не вставил новый бинарный файл sshd.
Проверьте наличие руткитов с помощью chrootkit или rkhunter.

уборка

Теперь, когда вы определили наличие руткита, вы должны убедиться, что все меняют свои пароли, и рекомендовать, чтобы они также меняли свои пароли на других сайтах.

Самым безопасным вариантом для очистки является переустановка и восстановление из резервной копии до ее запуска. Вы никогда не узнаете, был ли изменен какой-то, казалось бы, безобидный файл, и будет ли он заражен после очистки.