SSH зависает на pledge: network

Я настроил вход в ssh без пароля. Я мог подключаться через ssh и использовать sftp. Внезапно я больше не мог подключиться, и ssh зависал.

• Сервер: Ubuntu 16.04
• Клиент: Ubuntu 18.04

ssh --vvv user@host зависает на этапе pledge: network

...
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp SHA256:w7sj+s08FJPpL09IVtmXmGZOUgxVHGcgpjCL3vxzSaQ
debug3: sign_and_send_pubkey: RSA SHA256:w7sj+s08FJPpL09IVtmXmGZOUgxVHGcgpjCL3vxzSaQ
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to <host> ([<IP>]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: send packet: type 80
debug3: send packet: type 80
debug3: send packet: type 80
Timeout, server <host> not responding.

До этого я начал еще одну сессию ssh на том же хосте с тем же пользователем, и она зависла на этапе sign_and_send_pubkey, поэтому я начал ранее упомянутую sсh.

...
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp SHA256:w7sj+s08FJPpL09IVtmXmGZOUgxVHGcgpjCL3vxzSaQ
debug3: sign_and_send_pubkey: RSA SHA256:w7sj+s08FJPpL09IVtmXmGZOUgxVHGcgpjCL3vxzSaQ
debug3: send packet: type 50
Connection to <IP> port 22 timed out

• Я пробовал переустанавливать openssh-server на сервере и ssh на клиенте. Также перезапустил их (сервер и клиентский компьютер).

• Также пробовал подключаться с использованием пароля. Это просто изменило строку Authentication succeeded (password) в выводе.

• Кто-то сказал, что надо установить UsePAM no, это не сработало.

• Пробовал использовать -o IPQoS=0 и получил тот же вывод.

На сервере в syslog записано следующее:

...
May  7 07:26:10 host systemd[1]: Started Session c103 of user <user>.
May  7 07:26:10 host systemd[1]: Started Session c104 of user <user>.
May  7 07:26:26 host systemd[1]: Started Session 47 of user <user>.
May  7 07:26:33 host systemd[1]: Started Session 48 of user <user>.

Я думаю, что проблема на клиенте. Потому что мой друг мог подключиться к серверу со своего компьютера.

Для отладки ваших подключений SSH лучше смотреть /var/log/auth.log.

т.е.

sudo tail -n 250 -f /var/log/auth.log

Ваше соединение может также фильтроваться или блокироваться такими инструментами, как fail2ban.

Проверьте, если он запущен на вашем сервере:

sudo ps ax | grep fail2ban

Если он есть на вашем сервере, то по умолчанию он просматривает auth.log на предмет неудачных попыток входа и запрещает IP на 5 минут.

Если у вас нет fail2ban, убедитесь, что нет проблем с сетью или защитным экраном.

Используйте команду dmesg для чтения последних ошибок:

sudo dmesg -T

Просмотрите правила iptables с помощью:

sudo iptables -nvL

и также проверьте интерфейсы на наличие ошибок и превышений:

sudo ifconfig | grep errors

ifconfig является частью net-tools, поэтому убедитесь, что он установлен в вашей системе Ubuntu

sudo apt install net-tools

В моем случае причиной был падение rsyslogd. Я обнаружил это, потому что в /var/log/secure больше не было записей.

Таким образом, я перезапустил службу rsyslog, что решило проблему у нас.