Здесь аналогичное поведение , но я считаю, что это другая основная причина или, по крайней мере, требуется другое решение, поскольку этот сбой не связан с ключами SSH .
Наша компания проходит аудит Linux, и мне нужно включить блокировку учетной записи PAM на 3 попытки ввода неверного пароля. У меня нет предыдущего опыта работы с PAM.
Если я запускаю pam_tally2 -u testuser
сразу после запуска su testuser
, но до ввода пароля, pam_tally для сбоев уже равен 1, хотя Я еще не ввел пароль.
Я понимаю, что в случае, о котором я говорил выше, предварительное приращение пароля вызвано неудачным обменом ключами SSH, но после прочтения man su
похоже, что здесь не происходит обмена ключами. Итак, мой вопрос: "Почему su вызывает увеличение pam_tally перед вводом пароля?"
Я изо всех сил стараюсь убедиться, что все попытки / блоки входа совпадают между sshd_config, PAM, fail2ban и /etc/login.def, но это сложно, когда pam_tally считает события, которых я не ожидаю!
ОС - это сервер Ubuntu 14.04
Только изменения конфигурации PAM, внесенные на сервер, находятся в /etc/pam.d/common-auth
, добавив эту строку вверху:
auth required pam_tally2.so deny=3 unlock_time=900
Спасибо!
Внимательное прочтение того, что делает pam_tally2
, полностью объяснит наблюдаемое вами поведение. Вы ожидаете увидеть, сколько было неудачных попыток входа в систему; однако страница man
объясняет (выделено мной):
Этот модуль поддерживает счетчик попыток доступа
, поэтому он ведет себя точно так, как задумано. Когда вы su пользователя
, независимо от того, ввели ли вы пароль (правильный или неправильный), вы немедленно попытались получить доступ к . Когда вы впоследствии вводите правильный пароль, счет сбрасывается на 0
. Вы установили максимальное количество попыток на 3
, поэтому вы получите сообщение об ошибке, как только превысите , что - это 4-я попытка, которая вызывает ошибку.
Поведение такое правильно, и теперь, когда мы понимаем, что на самом деле делает pam_tally2
, это разумно.