SSH замораживается в залоге: сеть
Я устанавливаю вход в систему ssh без пароля. Я мог соединиться через ssh и также используемый sftp. внезапно, я не мог больше соединяться и замороженный ssh.
- Сервер: Ubuntu 16.04
- Клиент: Ubuntu 18.04
ssh --vvv user@host замораживания в залоге: сеть
...
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 no-more-sessions@openssh.com
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, таким образом, я запустил ранее сказанный ssh.
...
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-сервер с сервера и ssh от клиента. также перезапущенный они оба (Сервер и клиентский компьютер).
Также попробованный для принуждения соединения паролем. Это просто изменило строку
Authentication succeeded (password)в выводе.Кто-то сказал набор
UsePAM no, Это не работало.Попробованный
-o IPQoS=0и имел тот же вывод.
В сервере записал их в системном журнале:
...
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>.
Я думаю, что эта проблема от клиента. Поскольку мой друг мог соединиться с сервером от своего собственного компьютера.
1 ответ
Для отладки ваших 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
, а также проверьте свои интерфейсы на наличие ошибок и переполнений:
[ 114] ifconfig является частью сетевых инструментов, поэтому убедитесь, что он присутствует в вашем Ubuntu
sudo apt install net-tools