Server unexpectedly closed network connection putty что делать
Устранение неполадок SSH: ошибки протокола
В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки SSH. Остальные статьи расскажут, как определить и устранить конкретные ошибки:
В данном руководстве вы узнаете, что делать, если сбрасываются клиентские соединения, клиент жалуется на шифрование или возникают проблемы с неизвестным или измененным удаленным хостом.
После успешного подключения протокол SSH согласовывает зашифрованное соединение с клиентом на основе установления доверия. Есть несколько уникальных проблем, которые могут возникнуть на этом этапе. В этом мануале рассматриваются способы их определения, устранения и предотвращения.
Требования
Общие ошибки
Ошибка при проверке ключа хоста
Когда к серверу подключается SSH-клиент, сервер пытается идентифицировать себя с помощью ключа хоста. Если главный ключ изменился, вы можете увидеть такое предупреждение:
Обычно причиной этой ошибки является:
Чтобы решить эту проблему, вы можете очистить ключи хоста.
Соединение закрыто или сброшено
Иногда соединения устанавливаются на уровне сокета, но сбрасываются во время проверки ключей хоста. В PuTTY эта ошибка выглядит так:
Server Unexpectedly closed network connection
Клиент OpenSSH выдаёт такую ошибку:
Connection closed by 111.111.111.111 port 22
Эта ошибка, как правило, происходит по следующим причинам:
В таком случае необходим более тщательный анализ выходных данных протокола. В большинстве случаев данные нужно исследовать через веб-консоль и убедиться, что сервис в данный момент запущен и связан с требуемым портом.
Если сервис работает должным образом, убедитесь, что ключи хоста доступны. Если это не так, сгенерируйте и снова.
Ошибки переговоров с хостом
При инициировании протокола SSH генерируется общий секретный ключ. Это делается посредством шифрования, согласованного между клиентом и хостом. Если на данном этапе возникает несоответствие, переговоры срываются, и вы можете увидеть такие ошибки в PuTTY:
Couldn’t agree a client-to-server cipher (available: aes128-ctr, aes192-ctr, aes256-ctr)
Клиент OpenSSH сообщит:
Unable to negotiate with 111.111.111.111: no matching key exchange method found.
Their offer: diffie-hellman-group1-sha1
Источником этой ошибки может быть:
Чтобы решить эту проблему, вам необходимо правильно настроить шифрование на SSH-клиенте.
Устранение неполадок
Сброс ключей известных хостов
Ключи хоста обычно хранятся в файле
/.ssh/known_hosts клиента OpenSSH. PuTTY обычно хранит их в реестре Windows (HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys).
В PuTTY можно использовать диалоговое окно, чтобы разрешить подключение и обновить реестр (просто выберите Yes). Кроме того, вы можете удалить запись вручную.
На клиенте OpenSSH вы можете найти записи хоста в файле
/.ssh/known_hosts и удалить их вручную. Также можно использовать команду ssh-keygen.
Команда попытается получить доступ и очистить соответствующую запись хоста в файле known_hosts:
# Host 111.111.111.111 found: line 2
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.old
После этого попробуйте снова подключиться к серверу.
Проверка и генерирование SSH-ключей
Если таких файлов нет, сгенерируйте их с помощью команды ssh-keygen.
Команда выведет сгенерированные ключи:
ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519
Теперь попробуйте снова подключиться к серверу.
Настройка поддерживаемых шифров SSH
Вы можете настроить поддерживаемые SSH-шифры на клиентской машине, если нужна поддержка устаревшего шифрования (например, SHA1). Это не очень распространенная проблема; обычно она случается, если вы используете новый клиент SSH для подключения к устаревшему SSH-серверу, и они поддерживают разные шифры.
В OpenSSH поддержку SHA1 можно настроить с помощью опции KexAlgorithms. Введите в командную строку:
Клиент PuTTY должен поддерживать группу Диффи-Хеллмана (Connection → SSH → Kex).
Если у вас не получается самостоятельно исправить ошибки протокола SSH, вы можете обратиться за помощью к службе поддержки своего хостинг-провайдера.
Как решить проблему, вылетает ошибка «remote side unexpectedly closed network connection» работая через putty по ssh?
Есть docker ubuntu 18.04.3 LTS (GNU/Linux 4.2.8 armv71). Когда подключился через putty к ssh серверу, проходит секунд 10-15 и появляется ошибка
«remote side unexpectedly closed network connection».
Помогает команда sudo /etc/init.d/ssh restart
После этой команды, вроде все норм:
Если докер перегрузить, сервер работает, но после первого подключения по ssh все повторяется:-(
Dec 29 15:32:46 ubuntu-bionic-armhf-1 systemd1: Started OpenBSD Secure Shell server.
Dec 29 15:33:17 ubuntu-bionic-armhf-1 systemd1: ssh.service: Main process exited, code=killed, status=9/KILL
Dec 29 15:33:17 ubuntu-bionic-armhf-1 systemd1: ssh.service: Failed with result ‘signal’.
Dec 29 15:33:17 ubuntu-bionic-armhf-1 systemd1: ssh.service: Service hold-off time over, scheduling restart.
Dec 29 15:33:17 ubuntu-bionic-armhf-1 systemd1: ssh.service: Scheduled restart job, restart counter is at 4.
Dec 29 15:33:17 ubuntu-bionic-armhf-1 systemd1: Stopped OpenBSD Secure Shell server.
Dec 29 15:33:17 ubuntu-bionic-armhf-1 systemd1: Starting OpenBSD Secure Shell server.
Dec 29 15:33:17 ubuntu-bionic-armhf-1 sshd[454]: Server listening on 0.0.0.0 port 2222.
Dec 29 15:33:17 ubuntu-bionic-armhf-1 sshd[454]: Server listening on :: port 2222.
Dec 29 15:33:17 ubuntu-bionic-armhf-1 systemd1: Started OpenBSD Secure Shell server.
Dec 29 15:33:49 ubuntu-bionic-armhf-1 systemd1: ssh.service: Main process exited, code=killed, status=9/KILL
Dec 29 15:33:49 ubuntu-bionic-armhf-1 systemd1: ssh.service: Failed with result ‘signal’.
Dec 29 15:33:49 ubuntu-bionic-armhf-1 systemd1: ssh.service: Service hold-off time over, scheduling restart.
Dec 29 15:33:49 ubuntu-bionic-armhf-1 systemd1: ssh.service: Scheduled restart job, restart counter is at 5.
Dec 29 15:33:49 ubuntu-bionic-armhf-1 systemd1: Stopped OpenBSD Secure Shell server.
Dec 29 15:33:49 ubuntu-bionic-armhf-1 systemd1: Starting OpenBSD Secure Shell server.
Dec 29 15:33:49 ubuntu-bionic-armhf-1 sshd[456]: Server listening on 0.0.0.0 port 2222.
Dec 29 15:33:49 ubuntu-bionic-armhf-1 sshd[456]: Server listening on :: port 2222.
Dec 29 15:33:49 ubuntu-bionic-armhf-1 systemd1: Started OpenBSD Secure Shell serv
Пытался прописать строчки в /etc/ssh/sshd_config на сервере:
Как решить эту проблему, чтобы sshd не падал и стабильно работал. Спасибо!
Устранение неполадок SSH: проблемы с подключением к серверу
В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки SSH. Остальные статьи расскажут, как определить и устранить ошибки:
Для взаимодействия SSH-клиента с SSH-сервером необходимо установить базовое сетевое подключение. Это руководство поможет определить некоторые общие ошибки подключения, исправить их и предотвратить их возникновение в будущем.
Требования
Основные ошибки
Разрешение имени хоста
Большинство ошибок подключения возникает тогда, когда ссылка на хост SSH не может быть сопоставлена с сетевым адресом. Это почти всегда связано с DNS, но первопричина часто бывает не связана с DNS.
На клиенте OpenSSH эта команда:
может выдать ошибку:
ssh: Could not resolve hostname example.com: Name or service not known
В PuTTY может появиться такая ошибка:
Unable to open connection to example.com Host does not exist
Чтобы устранить эту ошибку, можно попробовать следующее:
Если у вас возникают проблемы с разрешением DNS на любом уровне, в качестве промежуточного решения можно использовать IP-адрес сервера, например:
ssh user@111.111.111.111
# вместо
ssh user@example.com.
Истечение времени соединения
Эта ошибка значит, что клиент попытался установить соединение с SSH-сервером, но сервер не смог ответить в течение заданного периода ожидания.
На клиенте OpenSSH следующая команда:
выдаст такую ошибку:
ssh: connect to host 111.111.111.111 port 22: Connection timed out
В PuTTY ошибка выглядит так:
Network error: Connection timed out
Чтобы исправить ошибку:
Отказ в соединении
Эта ошибка означает, что запрос передается на хост SSH, но хост не может успешно принять запрос.
На клиенте OpenSSH следующая команда выдаст ошибку:
ssh user@111.111.111.111
ssh: connect to host 111.111.111.111 port 22: Connection refused
В PuTTY ошибка появится в диалоговом окне:
Network error: Connection refused
Эта ошибка имеет общие с ошибкой Connection Timeout причины. Чтобы исправить её, можно сделать следующее:
Рекомендации по исправлению ошибок подключения
Брандмауэр
Иногда проблемы с подключением возникают из-за брандмауэра. Он может блокировать отдельные порты или сервисы.
В разных дистрибутивах используются разные брандмауэры. Вы должны научиться изменять правила и политики своего брандмауэра. В Ubuntu обычно используется UFW, в CentOS – FirewallD. Брандмауэр iptables используется независимо от системы.
Читайте также:
Чтобы настроить брандмауэр, нужно знать порт сервиса SSH. По умолчанию это порт 22.
Чтобы запросить список правил iptables, введите:
Такой вывод сообщает, что правил, блокирующих SSH, нет:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Если в выводе вы видите правило или политику по умолчанию REJECT или DROP, убедитесь, что цепочка INPUT разрешает доступ к порту SSH.
Чтобы запросить список правил FirewallD, введите:
Список, появившийся на экране, содержит все сервисы, которые поддерживаются брандмауэром. В списке должно быть правило:
dhcpv6-client http ssh
Если вы настроили пользовательский порт SSH, используйте опцию –list-ports. Если вы создали пользовательское определение сервиса, добавьте опцию –list-services, чтобы найти SSH.
Чтобы проверить состояние UFW, введите:
Команда вернёт доступные порты:
В списке должен быть порт SSH.
Проверка состояния сервиса SSH
Если вы не можете подключиться к серверу по SSH, убедитесь, что сервис SSH запущен. Способ сделать это зависит от операционной системы сервера. В более старых версиях дистрибутивов (Ubuntu 14.04, CentOS 6, Debian 8) используется команда service. Современные дистрибутивы на основе Systemd используют команду systemctl.
Метод проверки состояния сервиса может варьироваться от системы к системе. В более старых версиях (Ubuntu 14 и ниже, CentOS 6, Debian 6) используется команда service, поддерживаемая системой инициализации Upstart, а в более современных дистрибутивах для управления сервисом используется команда systemctl.
Примечание: В дистрибутивах Red Hat (CentOS и Fedora) сервис называется sshd, а в Debian и Ubuntu – ssh.
В более старых версия используйте команду:
service ssh status
Если процесс работает должным образом, вы увидите вывод, который содержит PID:
ssh start/running, process 1262
Если сервис не работает, вы увидите:
В системах на основе SystemD используйте:
systemctl status sshd
В выводе должна быть строка active:
Если сервис не работает, вы увидите в выводе inactive:
Чтобы перезапустить сервис, введите соответственно:
service ssh start
systemctl start sshd
Проверка порта SSH
Существует два основных способа проверить порт SSH: проверить конфигурационный файл SSH или просмотреть запущенный процесс.
Как правило, конфигурационный файл SSH хранится в /etc/ssh/sshd_config. Стандартный порт 22 может переопределяться любой строкой в этом файле, определяющей директиву Port.
Запустите поиск по файлу с помощью команды:
grep Port /etc/ssh/sshd_config
Если вы уже убедились, что сервис работает, теперь вы можете узнать, работает ли он на требуемом порте. Для этого используйте команду ss. Команда netstat –plnt выдаст аналогичный результат, но команду ss рекомендуется использовать для запроса информации сокета из ядра.
В выводе должно быть указано имя программы и порт, который она прослушивает. Например, следующий вывод сообщает, что сервис SSH прослушивает все интерфейсы и порт 22.
Символ * и 0.0.0.0 указывает, что все интерфейсы сервера прослушиваются. Строка 127.0.0.1 значит, что сервис не является общедоступным. В sshd_config директива ListenAddress должна быть закомментирована, чтобы прослушивать все интерфейсы, или должна содержать внешний IP-адрес сервера.
Если у вас не получается самостоятельно настроить соединение SSH, вы можете обратиться за помощью к службе поддержки своего хостинг-провайдера.
putty showing remote side unexpectedly close network connection
i cannot connect to my new droplet which is a ubuntu 18. when i try to connect from windows computer using putty/mobaXterm it shows remote side unexpectedly close network connection.
Related
Join 1M+ other developers and:
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
why can’t i connect to droplet?
Can you please make sure that the droplet is online and that the ssh port is open or your IP address whitelisted?
Do you have UFW enabled on your droplet? You can check this using the following command:
If UFW is disabled, which it is by default, you’ll see something like this:
To enable UFW, use this command:
To configure your server to allow incoming SSH connections, you can use this command:
Let me know how it goes.
i have done what you said. but it is still showing remote side unexpectedly close network connection
Could you please share the output of these two commands:
You can also try to enable Keep-Alive in PuTTY or try to connect using different ssh client.
Related
question
Server setup for multiple wordpress installs thats secure
I have read through the community some older posts for multiple wordpress installs on a single server. Could anyone inform me which environment would be best to setup for that, thats a more current than those articles? I want to setup something.
question
Does Digital Ocean provide NTP service to customer VMs?
I know I could go directly to pool.ntp.org but that seems antisocial. It seems like it would be better for everyone in a given datacenter to point at an NTP source inside that datacenter that gets its time from upstream.
question
Verify account by opening ticket
Hi there, I am trying to create a CPU optimised ticket but when I hover over the selection it says *»This size is currently restricted. Please open a ticket to verify your account»*. I imagine it refers to asking a question as it is opening a.
question
Thread: SSH Server unexpectedly closed network connection
Thread Tools
Display
SSH Server unexpectedly closed network connection
Hello, I haven’t used SSH from Putty for awhile now and I must have changed something which is now preventing me from accessing my home server.
I tried updating my iptables, but I’m not too sure exactly what I’m doing there.
I have port 49452 on both the public and lan forwarded to my tomato server. And I’m accessing SSH via my routers public IP on 49452.
I’m guessing I’ve enable the firewall which is blocking access, although running sudo ufw disable doesn’t do anything. It just returns Firewall stopped and disabled on system startup.
Re: SSH Server unexpectedly closed network connection
ufw is just an interface into iptables. Pick one interface and stick with that. Don’t mix to prevent confusion. Either use ufw for everything or nothing.
Sometimes a DNS issue makes it appear an entire subnet is down when it is not.
While not directly what you need, this link shows troubleshooting techniques for networking issues.
Re: SSH Server unexpectedly closed network connection
Sshd daemon is running, as I can connect locally using ssh ‘rhys@tomato’ and ssh ‘rhys@192.168.1.76’
I don’t have a windows machine at home to test putty.
Re: SSH Server unexpectedly closed network connection
There is the root issue to be solved. What is the exact command you are using?
Did the server internal IP change? This would mean the router port-forward isn’t going where you need it.
Personally, I let the router do port translation and have my internal ssh servers running on the default port, 22. Makes accessing sshd clear if using the router WAN interface or a local LAN address. I hope that makes sense. Not all low-end routers support port translation. Tomato definitely does.
Also, I’m confused about the difference between
a) the router
b) tomato
In my world, tomato runs as firmware on the router, so there isn’t any difference. You’ve gone out of your way to separate those for some reason. Why?