Каждый вход в AD SSH начинается с ошибки в audit.log
grep -iarn -C3 word .
Это выполнит поиск в текущем каталоге и всех подкаталогах (точно так же, как ваш find . -type f -print0), и покажет вам строки в этих файлах, соответствующие "слову", с тремя ведущими и последующими строками контекста, а также с именем файла и номерами строк, обозначающими каждую строку.
Вместо пустой строки между совпадениями, grep выдаст вам пары строк, на которых будут только --. Если вам действительно нужна пустая строка, потому что вы передаете вывод этой программы в другую программу, вы можете использовать эту версию:
grep -iarn -C3 word . | uniq | sed -e 's/^--$//'
Что касается вашего вопроса о том, как изучать советы по работе, страницы Unix man - довольно сухое чтение, но беглый просмотр страниц man для некоторых распространенных инструментов очень познавателен. Я также особенно рекомендую изучить Perl, если вы выполняете значительное количество операций с текстом в Linux или UNIX.
По умолчанию клиент OpenSSH пытается выполнить аутентификацию с открытым ключом, если вы уже создали ключи. Я предполагаю, что если вы выполните ls $ {HOME} /. Ssh / , вы увидите пару ключей - id_rsa и id_rsa.pub . Когда ваш клиент подключается к серверу, он пытается использовать эту пару ключей для входа в систему. Поскольку id_rsa.pub отсутствует в $ {HOME} /. Ssh / authorized_keys на вашем сервере, или этот файл имеет неправильные разрешения, sshd на сервере правильно помечает эту попытку входа в систему как неудачную. Попробуйте следующее:
ssh -o PubkeyAuthentication=no
Установка этого параметра предотвратит использование SSH-клиентом ключей в $ {HOME} /. Ssh / при попытке аутентификации на сервере. Если это не мешает отображению сообщений журнала, добавьте -vv в параметры клиента ssh, чтобы мы могли точно увидеть, что это за дела.
Извиняюсь за воскрешение старой темы, но я нашел ее при поиске похожей проблемы.
Существует вторая потенциальная причина ложноположительных сообщений об ошибках SSH в системах Linux, которые имеют более одного источника аутентификации для пользователей (, например. LDAP и локальные пользователи ). Конфигурация по умолчанию часто сначала проверяет локальных пользователей, используя модуль «pam _unix.so». Если пользователь не существует как локальный пользователь, это всегда будет генерировать сообщение журнала об ошибке, даже если проверка пользователя в другом источнике аутентификации будет успешной.
Если (как это часто бывает, )пользователи LDAP являются распространенным случаем, это можно решить для пользователей LDAP, сначала проверив LDAP, а затем попробовав локальную аутентификацию. Например, для Debian 10 я изменил две строки в /etc/pam.d/common-authс:
# here are the per-package modules (the "Primary" block)
auth [success=2 default=ignore] pam_unix.so nullok_secure
auth [success=1 default=ignore] pam_ldap.so minimum_uid=1000 use_first_pass
# here's the fallback if no module succeeds
auth requisite pam_deny.so
по
# here are the per-package modules (the "Primary" block)
auth [success=2 default=ignore] pam_ldap.so minimum_uid=1000
auth [success=1 default=ignore] pam_unix.so nullok_secure use_first_pass
# here's the fallback if no module succeeds
auth requisite pam_deny.so
=> две строки с "success=" меняются местами, числа изменяются в соответствии с новым местоположением ("success=" пропускает указанное количество строк при успешном возврате из модуля ), а "use _флаг первого _прохода» перемещен, чтобы оставить его на второй строке
Это не полное решение, так как это означает, что LDAP проверяется для локальных пользователей (, что может быть нежелательно)
Существует решение Redhat, документирующее другой способ решения этой проблемы для Redhat, таких как дистрибутивы Linux, которые, как мне кажется, не имеют этого недостатка. (pam _localuser.so проверяет, существует ли пользователь как локальный пользователь,перед попыткой аутентификации):
https://access.redhat.com/solutions/881103
Должна быть возможность реализовать такое же решение для Debian-подобных систем, но я этого не сделал.