Удаленный сервер, случайным образом зависающий на входе в систему ssh

Обновить до новой информации:

Я бы не начал с Fail2ban , как если бы не правильно настроен, вы можете в конечном итоге заблокировать себя из собственного ящика.

Я бы вместо этого просто начну с изменение вашего порта в SSHD_CONFIG на более высокий номер порта и изменив пароль входа вашего пользователя на что-то сильнее 20 + символов (не забудьте перезапустить SSHD). И посмотрите, вырезают ли это на ваши соединения входа в систему. Если нет, чем я бы предложил пройти более экстремальный маршрут и настроить Fail2ban. Но снова будьте очень осторожны и тщательно прочитайте документацию по установке.

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

Создание отладки SSHD на порту 6022 (вам нужно сделать это, потому что исходное SSHD уже работает на порту 22).

# nohup /usr/sbin/sshd -p 6022 -ddd > ~/sshd.log 2>&1 &

• NOHUP : Запустите команду, невосприимчивую к зависанию, с выходом в нетехнику
• -P : установить номер порта (в этом случае 6022)
• > ~ / sshd.log 2 > & 1 : перенаправить stdout и STDERR в ~ / sshd.log
• & : если команда заканчивается оператором управления, и оболочка выполняет команду на заднем плане подставка. Оболочка не ждет окончания команды, и статус возврата равен 0.

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

# ssh -vvv -p 6022 user@remotehostname
[OR]
# ssh -vvv -p 6022 user@remoteIPaddress

В следующий раз, когда вы повесьте, вы можете увидеть, если:

1. Это было просто SSHD, работающим на порту 22, это была проблема? Делал 6022 успех?
2. Если 22 и 6022 оба зависают, то вы можете сравнить журналы с вывода Server Server и вывод клиента VVVV, чтобы увидеть, если вы обнаружите больше информации о проблеме.

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

[root ~]# ifconfig            # I removed sensitive information:
eth0      Link encap:Ethernet
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

Я бы предложил:

1. Проверьте, если клиенты правильно закрывают свои соединения - в некоторых ситуациях Сервер может сохранить соединения не разглаженным и ударяет его пределы ( Netstat - ваш друг)
2. Проверьте журналы для неудачных попыток регистрации. Это может быть ваш SSH-сервер перегружен в некоторой атаке B жестокой силы.
3. Установка Fail2ban - запретить IPS, которые выполняют эти попытки (настроить его, чтобы доверять вашим IP-адресам, чтобы избежать блокировки себя)
4. Проверьте, определяются ли все имения в /etc/resolv.conf Работает нормально
5. TUNE SSHD

SSHD_CONFIG должно иметь как минимум:

 Port 57322 # not 22 and some high one - above 1024
 Protocol 2
 UseDNS no # it'll speed-up the connection process a bit (or even a lot if your DNS doesn't work well)

6. RUN IFCONFIG несколько раз и проверьте, если нет ошибок или Упал Увеличение
7. , как @devnull Check Check MTU ( TCPDUMP TCPDUMP - это ваш друг здесь, но это будет просто будет установить его ниже и проверять, помогает ли это или не с Набор IP-ссылок ETH0 MTU 1462 может помочь вам, если это виртуальная вирция на соединенном интерфейсе - но вы можете установить его намного ниже для теста)