Eсть подобное поведение здесь но я считаю, что это другая основная причина или, по крайней мере, требуется другое решение, поскольку этот сбой не связан с ключами 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 user, независимо от того, набирали ли вы пароль (правильный или неправильный), вы сразу попытался доступ. Когда вы впоследствии вводите правильный пароль, счет сбрасывается на 0. Вы установили максимальное количество попыток 3, поэтому вы получите сообщение об ошибке, как только превышен это - это 4-я попытка, которая вызывает ошибку.
Поведение правильное, и теперь, когда мы понимаем, что pam_tally2 на самом деле, это разумно.