Есть ли простой способ не регистрировать конкретное событие sshd?

Инструмент мониторинга моего хостера выполняет регулярные соединения с ssh на порту 22, чтобы увидеть или услугу.

Это загромождает сообщения my / var / log / с такими сообщениями:

Dec 13 22:20:17 sshd[29487]: Did not receive identification string from 80.xx.xx.xx 

Есть ли простой способ заглушить это сообщение «Не получил идентификационную строку из» для этого конкретного ip?

3 Solutions collect form web for “Есть ли простой способ не регистрировать конкретное событие sshd?”

Я думаю, что с sshd легко sshd .

Я подозреваю, что это дизайнерский выбор со стороны авторов (обычно людей OpenBSD), поскольку они почти всегда «ошибаются» на стороне безопасности – в этом случае, не предоставляя ручку для нас, которая могла бы подавить важные Сообщения.

Вы сказали «легко», так что это может быть весь ответ, который вам нужен.

Но если вы можете подумать о менее простых вариантах, мой совет: не делайте этого , и вот почему.

Если вы похожи на меня, то ваша основная мотивация для этого вопроса состоит в том, чтобы выставить заметные элементы в ваших журналах и уменьшить шум. Ты не один. 🙂

На практике так много типов сообщений:

  • хорошо известно,
  • трудно отключить, и
  • никогда не действовать

… то, что вы действительно хотите, это отфильтровать его . Сделайте это вместо этого.

Например, я написал сценарий, который отфильтровывает «неинтересные» элементы в журналах предыдущего дня и отправляет мне ежедневный отчет. Вы должны быть очень осторожны с вашими фильтрами, но если все сделано правильно, это заставка в реальном времени – и это сделает материал, который действительно нуждается в вашем внимании .

Я, конечно, иногда просматриваю свои сырые журналы, и у меня есть другие способы поймать действительно актуальные вещи. Но не хватает часов в день, чтобы каждый день рубить ваши журналы вручную, особенно когда у вас есть несколько ящиков для стада, но вы не достаточно большой магазин, чтобы гарантировать крупномасштабную обработку журнала.

Все, что было сказано, на всякий случай у вас есть действительно веская причина для этого (и решение MaxMackie не соответствует вашему прецеденту, так что вам действительно нужно, чтобы эти сообщения исчезли, before они попадут в syslog), я думаю, что у вас есть два варианта:

0,1. Измените источник.

Но не делайте этого . Слишком много накладных расходов и рисков – слишком много задержек между объявлением об уязвимости и возможностью обновления.

0,2. Сделайте sshd отправленным его выходом в другое место и отправьте его в syslog самостоятельно.

FreeBSD позволяет указать, какие параметры должны быть переданы sshd при запуске в /etc/rc.conf или /etc/rc.conf.local , используя значение sshd_flags . Скажите sshd для запуска с параметром -d (debug) и -e (log to standard error):

 sshd_flags="-d -e" 

Затем вы можете передать вывод в logger или в Sys::Syslog Perl (с помощью обертки для очистки любых странностей). Это нетривиально, поскольку говорить, что демон является не-демоном, означает, что вам нужно самому воссоздать многие функции. При необходимости я могу предоставить более подробную информацию.

Но лучше всего фильтровать.

Не записывая сценарий для анализа через /var/log/messages и удаляя эти строки (это возможно, вы даже можете запустить его через cron ), вы будете отключать или перенаправлять весь вывод ssh . Это не лучшая идея, когда вы можете получить некоторые соответствующие журналы, которые вы хотите увидеть.

Я бы сделал так:

 #! /bin/bash sed "/$search/d" /var/log/messages >/var/log/tmp mv /var/log/tmp /var/log/messages 

Сохраните это где-то в безопасности и пропустите cron каждый день или около того. Я не знаю частоты, с которой ваш провайдер запускает sshd чтобы вы могли настроить время выполнения в соответствии с вашими потребностями. Для получения дополнительной информации о добавлении правила в cron (cronjob) см. Этот очень хороший учебник .

И наоборот, если у вас есть доступ к скрипту, который запускает ssh (что я сомневаюсь, что вы это делаете), и вы можете редактировать его (что я сомневаюсь, вы можете), вы можете вызвать ssh с помощью ssh -q . Аргумент q делает ssh «тихим», что означает, что ничего не регистрируется. Это опасно и его следует избегать. Если вы сможете отредактировать файл, я бы попросил вашего хостинг-провайдера убедиться, что он находится в рамках вашего соглашения.

Кроме того, вы можете связаться со своим провайдером, объяснить свою проблему и спросить их, есть ли что-то, что они могут сделать (или позволить вам делать), для изменения демона ssh .


TL; DR Насколько я знаю, невозможно остановить только одно сообщение из ssh . Однако вы можете анализировать свой файл сообщений через определенные промежутки времени, чтобы очистить эти строки, или если вы найдете, где ваш провайдер запускает sshd , вы можете отправить ему тихую команду.

Вы посмотрели документацию ?

Существует LogLevel QUIET|FATAL|ERROR|INFO умолчанию используется информация.

LogLevel ERROR отключил эти сообщения для спам-сообщений.

  • ssh без пароля в AIX
  • Как разрешить ssh-соединение отказано в AIX?
  • RHEL 7 (CentOS 7) security / ssh / sshd_config рекомендует
  • Команда ssh неожиданно продолжается в другой системе после завершения ssh
  • Может ли чрезмерное использование ресурсов фактически заставлять пользователей быть неспособными SSH к Linux?
  • Предполагая, что sshd разрешает только аутентификацию с открытым ключом, как мне регистрировать отпечатки пальцев?
  • Как начать SSHD в начале Fedora?
  • Разрешающая способность sshd_config не влияет
  • CentOS 7 добавляет нового пользователя с привилегиями root
  • SSH на сервер localhost
  • SSH занимает слишком много времени, чтобы запросить пароль
  • Linux и Unix - лучшая ОС в мире.