В хвосте /var/log/auth.log Я заметил, что там несколько записей вводятся (мгновенно) по минутам для пользователя «foo». Лично у меня было только одно соединение, открытое как пользователь root_bar, пока auth.log (образец журнала ниже). Как видите, для входящих SSH-соединений нет информации об IP. Как лучше всего отслеживать IP-адрес входящих SSH-соединений?
Aug 10 14:30:04 ps2000 suexec: (pam_unix) session opened for user root_bar by (uid=999)
Aug 10 14:30:04 ps2000 suexec: (pam_unix) session closed for user root_bar
Aug 10 14:30:06 ps2000 suexec: (pam_unix) session opened for user root_bar by (uid=999)
Aug 10 14:30:06 ps2000 suexec: (pam_unix) session closed for user root_bar
Aug 10 14:30:08 ps2000 CRON[16879]: (pam_unix) session closed for user root_bar
Aug 10 14:30:14 ps2000 suexec: (pam_unix) session opened for user root_bar by (uid=999)
Aug 10 14:30:14 ps2000 suexec: (pam_unix) session closed for user root_bar
Aug 10 14:30:16 ps2000 suexec: (pam_unix) session opened for user root_bar by (uid=999)
Aug 10 14:30:16 ps2000 suexec: (pam_unix) session closed for user root_bar
Aug 10 14:30:27 ps2000 suexec: (pam_unix) session opened for user root_bar by (uid=999)
Aug 10 14:30:27 ps2000 suexec: (pam_unix) session closed for user root_bar
Aug 10 14:30:39 ps2000 suexec: (pam_unix) session opened for user root_bar by (uid=999)
Aug 10 14:30:39 ps2000 suexec: (pam_unix) session closed for user root_bar
Отказ от ответственности: имя сервера и вся информация о пользователе были изменены по соображениям безопасности.
Исправление: Вопрос "Отслеживание входящих SSH-соединений"должным образом ответили постеры ниже. Сообщение suexec (pam_unix) сеанс не обязательно указывает на какие-либо sshd активность, как пояснил @aseq, и я разместил это как вопрос sshd из-за моего незнания. Поскольку исходный вопрос и ответы на него полезны, я принимаю наиболее полезный ответ. Я думаю отслеживание suexec: (pam_unix) session кандидат на отдельный вопрос.
Окончательное обновление: Я обнаружил, что сообщения выше имели отношение к sshd. После некоторых настроек в /etc/pam.d/common-auth я начал видеть такие строки, как
Aug 10 16:45:23 candy_bass sshd[427]: (pam_unix) session opened for user summer_flag by (uid=0)
Aug 10 16:45:23 candy_bass sshd[427]: PAM pam_parse: expecting return value; [...sucess=1 default=ignore]
Aug 10 16:45:23 candy_bass sshd[427]: PAM pam_parse: expecting return value; [...sucess=1 default=ignore]
Aug 10 16:45:23 candy_bass sshd[427]: Accepted publickey for summer_flag from xxx.zzz.yyy.abc port 35964 ssh2
Aug 10 16:45:23 candy_bass sshd[427]: (pam_unix) session opened for user summer_flag by (uid=0)
Aug 10 16:45:23 candy_bass pam_limits[427]: setrlimit limit #11 to soft=-1, hard=-1 failed: Operation not permitted; uid=0 euid=0
Aug 10 16:45:23 candy_bass pam_limits[427]: setrlimit limit #12 to soft=-1, hard=-1 failed: Operation not permitted; uid=0 euid=0
Aug 10 16:45:23 candy_bass sshd[427]: (pam_unix) session closed for user summer_flag
Так это является связаны с sshd, однако, поскольку это так характерно для поставщика токенов аутентификации (имя которого я не раскрываю в целях конфиденциальности), я думаю, что поставщик может лучше решить эту проблему.
Как выглядят эти записи журнала?
Сервер ssh должен по умолчанию регистрировать IP-адреса в /var/log/auth.log и других файлах журнала, например:
Aug 1 12:21:30 example.host sshd[1174]: Failed password for invalid user example from 192.0.2.1 port 9460 ssh2
Aug 1 12:21:32 example.host sshd[1176]: Invalid user root from 192.0.2.10
Если в записях журнала, о которых вы спрашиваете, нет строки «sshd», я сомневаюсь, что они действительно пришли с сервера ssh, и вам нужно поискать в другом месте. Посмотрите на строку, которая идет после имени хоста, она говорит вам, какая программа записывала журнал.
Вы также можете проверить / etc / ssh / sshd_config и убедиться, что уровень журнала правильный, по умолчанию при сжатии:
# Logging
SyslogFacility AUTH
LogLevel INFO
Возможно, увеличение количества подробностей поможет раскрыть больше информации. Записи журнала, которые вы добавили в свой вопрос, должны предшествовать записи журнала, как показано выше.
Вы увидите, что соединения открываются и закрываются для SSH всякий раз, когда соединение установлено, независимо от того, успешно ли кто-то вошел в систему или нет.
Чтобы просмотреть дополнительную информацию об успешных и неудачных попытках входа в систему через ssh, см. /var/log/secure и / или /var/log/messages.
*** Обратите внимание, что местоположение может отличаться в зависимости от вашего дистрибутива Linux и / или вашего хостинг-провайдера. *
Я разрешил шквал открытий и закрытий на auth.log проблема, закомментировав ChallengeResponseAuthentication и UsePAM настройки на /etc/ssh/sshd_config из
ChallengeResponseAuthentication yes
UsePAM yes
к
#ChallengeResponseAuthentication yes
#UsePAM yes
Другими словами, я временно отключил модуль PAM, пока выясняю у его поставщика правильные настройки.
Если у вас есть доступ к пользователю root на сервере, вы можете использовать iptables для реализации оператора LOG для всех НОВЫХ подключений на TCP-порту 22. Это добавит информацию в файл / var / log / messages, указывающую, какие подключения идут. входящий на ваш сервер.
Если вы используете IPv6, я полагаю, что брандмауэр будет iptables6.