Журнал sshd заполнен "Не получено идентификационной строки от"

На самом деле, это было от моего хостинг-провайдера - они спамят мой VPS каждые 6 секунд, чтобы показать состояние моего сервера на своей веб-консоли. Мой сервер отображается как активный, если мой sshd отвечает на них.

Я только что установил OpenVPN и разрешил SSH только через это - так, по словам моих провайдеров, мой сервер может работать на 100% простоев.

Скорее всего, это keepalive (проверка того, что сервер отвечает) от комм. устройство.

Такие сообщения генерируются SSH, когда кто-то пытался получить к нему доступ, но не завершил шаги. Например, если NMS проверяет, работает ли порт ssh 22 или нет, он просто попытается подключиться к порту 22, а если соединение установится успешно, он будет зависать, в таких случаях SSH сообщает об этом.

Так что из-за сканирования порта SSH.

Попробуйте изменить порт SSH с 22 на другой в sshd_config:

sudo nano /etc/ssh/sshd_config

Если это не останавливает сообщения, проблема также может быть вызвана следующими причинами: Freebpx вызывает ошибки sshd в файле /var/log/secure log или смотрите обсуждение здесь "Не получена строка идентификации" в auth.log на форумах Ubuntu.

Это также может быть попытка выполнить хорошо известный эксплойт переполнения буфера.

Это задокументировано в фильтре /etc/fail2ban/filter.d/sshd-ddos.conf, который вы можете включить, чтобы защитить себя этими попытками взлома:

Fail2Ban ssh filter for at attempted exploit
The regex here also relates to a exploit:
http://www.securityfocus.com/bid/17958/exploit
The example code here shows the pushing of the exploit straight after
reading the server version. This is where the client version string normally
pushed. As such the server will read this unparsible information as
"Did not receive identification string".

Строка назначения для этого эксплойта (угадайте, что?) "Не получила идентификационную строку от..."

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

Можно настроить фильтр fail2ban (через директиву ignoreregex), чтобы соответствующим образом игнорировать легитимную попытку.

В моем случае эти записи в журнале создавались каждые 5 минут из-за регулярного сканирования службы Samhain, хотя я использовал какой-то настраиваемый порт (отличный от 22) для SSH-сервера. Отключение обнаружения новых служб должно предотвратить появление этих раздражающих записей журнала (но также может ослабить защиту вашей IDS).

В моем случае это было вызвано проверкой работоспособности моего Elastic Load Balancer (ELB). Я действительно хочу, чтобы балансировщик нагрузки гарантировал sssdработает на моем хосте, поэтому это сообщение ожидалось в моем случае использования. В моем конкретном случае использования AWS FireLens я смог отфильтровать эти сообщения с помощью exclude-patterns свойство объекта конфигурации.

Эта проблема была отмечена выше в комментарии, но я пропустил ее в первые несколько раз, когда читал этот пост, поэтому я хотел опубликовать ее как отдельный ответ верхнего уровня.

Если вам интересно, кто сканирует порт или пытается выполнить аутентификацию на вашем компьютере, просто проверьте:

# whois 211.110.33.50

# KOREAN(UTF8)

조회하신 IPv4주소는 한국인터넷진흥원으로부터 아래의 관리대행자에게 할당되었으며, 할당 정보는 다음과 같습니다.

[ 네트워크 할당 정보 ]
IPv4주소           : 211.110.0.0 - 211.110.239.255 (/17+/18+/19+/20)

и т.п.