На виртуальной машине, которую я инициализирую, я могу войти в систему как один пользователь без полномочий root (admin) но не другой (tbbscraper) по SSH с аутентификацией с открытым ключом. Единственное сообщение об ошибке, которое я могу найти в любом файле журнала, это
Sep 18 17:21:04 [REDACTED] sshd[18942]: fatal: Access denied for user tbbscraper by PAM account configuration [preauth]
Со стороны клиента синдром
$ ssh -v -i [REDACTED] tbbscraper@[REDACTED]
...
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: [REDACTED]
debug1: Authentications that can continue: publickey
debug1: Trying private key: [REDACTED]
debug1: read PEM private key done: type RSA
Connection closed by [REDACTED]
Изменение tbbscraper на admin позволяет успешно войти в систему: debug1: Authentication succeeded (publickey). появляется вместо сообщения «Соединение закрыто».
Это не похоже на проблему с разрешениями ...
# for x in admin tbbscraper
> do ls -adl /home/$x /home/$x/.ssh /home/$x/.ssh/authorized_keys
> done
drwxr-xr-x 3 admin admin 4096 Sep 18 17:19 /home/admin
drwx------ 2 admin admin 4096 Sep 18 16:53 /home/admin/.ssh
-rw------- 1 admin admin 398 Sep 18 17:19 /home/admin/.ssh/authorized_keys
drwxr-xr-x 3 tbbscraper tbbscraper 4096 Sep 18 17:18 /home/tbbscraper
drwx------ 2 tbbscraper tbbscraper 4096 Sep 18 17:18 /home/tbbscraper/.ssh
-rw------- 1 tbbscraper tbbscraper 398 Sep 18 17:18 /home/tbbscraper/.ssh/authorized_keys
# cmp /home/{admin,tbbscraper}/.ssh/authorized_keys ; echo $?
0
... ни проблема контроля доступа на уровне PAM ...
# egrep -v '^(#|$)' /etc/security/*.conf
#
... так что ни один из существующих ответов на подобные вопросы, похоже, не подходит. Единственное, что у меня есть, это:
root@[REDACTED] # su - admin
admin@[REDACTED] $
но
root@[REDACTED] # su - tbbscraper
su: Authentication failure
(Ignored)
tbbscraper@[REDACTED] $
что предполагает некоторую более крупномасштабную проблему с PAM, но я не могу найти ничего явно неправильного с материалом в /etc/pam.d. Любые идеи?
Виртуальная машина - это экземпляр EC2, ОС - Debian 7.1 (стандартный AMI Amazon).
В конце концов, оказалось, что это опечатка с одним символом в /etc/shadow. Найди отличие:
admin:!:15891:0:99999:7:::
tbbscraper:!::15966:0:99999:7:::
Правильно, после восклицательного знака стоит два двоеточия. tbbscraper линия. Это помещает все поля в одно и заставляет PAM думать, что срок действия учетной записи истек 8 января 1970 года.
Спасибо, что разместили свой вопрос. Я получал ту же ошибку, но моя проблема не была связана с теневым файлом. Я нашел свое исправление и хотел опубликовать ответ также для всех, кто искал эту ошибку в Google. Сначала возникает вопрос о сбое сервера.
Попробуйте проверить /etc/security/access.conf !
Мы используем Active Directory для аутентификации, но мне нужно было войти в систему как локальный пользователь, не являющийся пользователем AD (jenkins). Мой босс изначально установил коробку с этими строками в /etc/security/access.conf:
+:root:ALL
-:ALL:ALL
Я изменил его на следующий, и теперь логины работают; Мне даже не пришлось перезапускать какие-либо службы.
+:jenkins:ALL
+:root:ALL
-:ALL:ALL
Было такое же сообщение об ошибке. Выключил sshd и перезапустил его в режиме отладки
/usr/sbin/sshd -ddd
это указывало на причину:
debug3: User autossh not allowed because account is locked
...
input_userauth_request: invalid user <username> [preauth]
Проверенный счет:
passwd -S <username>
который показал, что учетная запись заблокирована (флаг «L»). Разблокируйте учетную запись, установив новый пароль:
passwd <username>
Готово.
Сегодня утром у меня такая же проблема, но сервер аутентифицирует пользователей по Active Directory. Оказывается, срок действия пароля домена пользователя истек.
В моем случае я переименовал локальных пользователей CentOS 6 и забыл переименовать их в / etc / shadow (которые не имеют пароля без ключа, не всплывали у меня в голове), поэтому записи для новых имен пользователей были просто отсутствует в / etc / shadow. В / var / log / secure это давало мне ошибку unix_chkpwd и доступ запрещен PAM:
unix_chkpwd[12345]: could not obtain user info (user2)
sshd[12354]: fatal: Access denied for user user2 by PAM account configuration
В моем случае это было попадание мусора в "/ etc / tcb / USER / shadow" после повреждения rootfs ext4 в "интересных" условиях; это выглядело довольно текстово, поэтому не было замечено во время первоначальной проверки (не могу переустановить узел прямо сейчас, но придется).
У меня была такая же проблема, и ни один из предложенных вариантов не работал. Но я нашел на одном из форумов (https://ubuntuforums.org/showthread.php?t=1960510) "обходной путь", который работал отлично.
редактировать /etc/ssh/sshd_config и установить
UsePAM no
Хотя это, вероятно, не настоящее решение, потому что с моей машиной что-то определенно не так (вчера она работала нормально!), Это, по крайней мере, работает.