Remote side unexpectedly closed network connection ошибка

Есть docker ubuntu 18.04.3 LTS (GNU/Linux 4.2.8 armv71). Когда подключился через putty к ssh серверу, проходит секунд 10-15 и появляется ошибка «remote side unexpectedly closed network connection».

5e08b92ce94af328515702.png

Смотрю на сервере командой sudo ssh status, ssh не рабочий(:

5e08b94d02dcd030270472.png

Помогает команда sudo /etc/init.d/ssh restart

После этой команды, вроде все норм:

5e08b95fc3d41513624625.png

Если докер перегрузить, сервер работает, но после первого подключения по ssh все повторяется:-(

Вывод команды #journalctl -u ssh, и ее последний результат:

Dec 29 15:32:46 ubuntu-bionic-armhf-1 systemd[1]: Started OpenBSD Secure Shell server.
Dec 29 15:33:17 ubuntu-bionic-armhf-1 systemd[1]: ssh.service: Main process exited, code=killed, status=9/KILL
Dec 29 15:33:17 ubuntu-bionic-armhf-1 systemd[1]: ssh.service: Failed with result ‘signal’.

Dec 29 15:33:17 ubuntu-bionic-armhf-1 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Dec 29 15:33:17 ubuntu-bionic-armhf-1 systemd[1]: ssh.service: Scheduled restart job, restart counter is at 4.
Dec 29 15:33:17 ubuntu-bionic-armhf-1 systemd[1]: Stopped OpenBSD Secure Shell server.
Dec 29 15:33:17 ubuntu-bionic-armhf-1 systemd[1]: 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 systemd[1]: Started OpenBSD Secure Shell server.
Dec 29 15:33:49 ubuntu-bionic-armhf-1 systemd[1]: ssh.service: Main process exited, code=killed, status=9/KILL
Dec 29 15:33:49 ubuntu-bionic-armhf-1 systemd[1]: ssh.service: Failed with result ‘signal’.

Dec 29 15:33:49 ubuntu-bionic-armhf-1 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Dec 29 15:33:49 ubuntu-bionic-armhf-1 systemd[1]: ssh.service: Scheduled restart job, restart counter is at 5.
Dec 29 15:33:49 ubuntu-bionic-armhf-1 systemd[1]: Stopped OpenBSD Secure Shell server.
Dec 29 15:33:49 ubuntu-bionic-armhf-1 systemd[1]: 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 systemd[1]: Started OpenBSD Secure Shell serv

По совету @pfg21 пробовал в /etc/ssh/sshd_config на сервере следующие параметры
TCPKeepAlive yes
ClientAliveInterval 60
ClientAliveCountMax 360
не помогает….

Как решить эту проблему, чтобы sshd не падал и стабильно работал. Спасибо!

A PuTTY session left idle will disconnect at a time determined by the host server. Try enabling keep-alives in PuTTY. This causes PuTTY to send null SSH packets to the remote host periodically, preventing the session from timing out.

The PuTTY client can be configured to always establish a connection which will not time out due to inactivity. To create and save a new keep-alive connection, follow these steps:

  1. Open the PuTTY application, and go to the Options panel (labeled «Category») on the left of the window.
  2. Select (click) the «Connection» item.
  3. In the ​​»Sending of null packets to keep the session active» area on the right, change the default value of «Seconds between keepalives» from 0 (turn off) to 1800 (30 minutes).
  4. Select the «Enable TCP keepalives (SO_KEEPALIVE option)» check box.
    Note: This option may not be available in older versions of the PuTTY client.
  5. On the topmost left side of the Options panel, select (click) «Session».
  6. In the «Host Name (or IP Address)» field, enter the destination host name or IP address (e.g., «destination.ipaddress.here.com» or «192.168.1.1»).
  7. In the «Saved Sessions» text-entry box, provide a name for the session (e.g., «savedsession»).
  8. Select «Save».

To use the modified session settings, select it from the «Saved sessions» list, then click the buttons marked «Load» and «Open».

If your connected sessions still time out, enter a lower number of seconds into the «Seconds between keepalives» value.

answered Oct 15, 2014 at 7:20

afrab_null's user avatar

3

The server could have been hardened. The reason could be a) the client ip may be not configured in /etc/allowhosts and/or b) unix/linux firewall rule/selinux is not permitting.

answered Nov 9, 2018 at 7:49

AVA's user avatar

I had the same problem for a long time, I use putty to connect to AWS linux instances (some remote cloud servers)
I read about fixing it with keepAlives in several pages several pages, tried it but to no avail.

And just yesterday, while looking for some color scheme settings I found this:
https://github.com/jblaine/solarized-and-modern-putty

Besides adjusting the colors of the terminal it does apply some sane defaults (Like the forementioned KeepAlives to 59 seconds plus others), and guess what? I havent had any closed connection for two whole days.

answered May 27, 2016 at 2:08

Mario Chapa's user avatar

I tried everything above and nothing worked until this

vi /etc/ssh/sshd_config
ClientAliveInterval 60
restart deamon sshd

also switched to kitty an alternative putty clone which is much better

Ramhound's user avatar

Ramhound

41.9k35 gold badges103 silver badges131 bronze badges

answered Nov 10, 2020 at 21:32

Amarpreet 's user avatar

1

You were idle longer than the session timeout on the remote device, so it closed the session and PuTTy wasn’t expecting it.

answered Oct 15, 2014 at 5:50

cpt_fink's user avatar

cpt_finkcpt_fink

3852 silver badges8 bronze badges

3

You must log in to answer this question.

Not the answer you’re looking for? Browse other questions tagged

.

qaa-engineer.ru > Вопросы и ответы > Как решить проблему, вылетает ошибка «remote side unexpectedly closed network connection» работая через putty по ssh?

Пользователям, работающим с SSH-клиентом PuTTY, иногда приходится столкнуться с сообщением об ошибке «remote side unexpectedly closed network connection» («удаленная сторона неожиданно закрыла сетевое соединение»), которая может вызывать некоторые неудобства и затруднения в выполнении задач по удаленному управлению.

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

1. Проверьте правильность настроек подключения:
Первым шагом, который следует предпринять, — убедиться, что вы правильно настроили подключение в вашем SSH-клиенте. Убедитесь, что вы указали правильный IP-адрес или хост-имя, порт (по умолчанию 22), а также выбрали правильный протокол (SSH).

2. Проверьте состояние сервера SSH:
Ошибка «remote side unexpectedly closed network connection» может быть вызвана проблемами с сервером SSH. Убедитесь, что сервер SSH работает должным образом и принимает соединения. Попробуйте выполнить подключение с другого компьютера или с другим SSH-клиентом, чтобы исключить возможные проблемы с вашим конкретным клиентом.

3. Потеря сетевого соединения:
Иногда это сообщение об ошибке может быть вызвано проблемами с сетевым соединением. Если ваше соединение нестабильно или медленное, сервер SSH может закрыть соединение. Попробуйте проверить состояние вашего сетевого подключения, устранить проблемы с сетью, например, перезапустить маршрутизатор или модем. Если вы работаете через Wi-Fi, попробуйте подключиться к сети через провод, чтобы проверить, не вызывает ли проблемы беспроводное соединение.

4. Увеличьте тайм-аут SSH:
Один из возможных вариантов решения проблемы «remote side unexpectedly closed network connection» — увеличение тайм-аута SSH-соединения. По умолчанию PuTTY устанавливает тайм-аут в 2 минуты. Вы можете попытаться увеличить это значение, чтобы предоставить больше времени для установления соединения и передачи данных. Для этого откройте PuTTY, выберите ваше соединение, перейдите в настройки и увеличьте значение тайм-аута.

5. Проверьте настройки брандмауэра:
Если у вас включен брандмауэр, убедитесь, что правильно настроены его правила. Брандмауэры иногда могут блокировать SSH-трафик, вызывая сообщение об ошибке. Убедитесь, что порт SSH (по умолчанию 22) открыт и разрешен в вашем брандмауэре.

6. Обновите PuTTY или используйте другой SSH-клиент:
Последний вариант — обновить SSH-клиент PuTTY до последней версии или попробовать использовать другой SSH-клиент, чтобы убедиться, что проблема не связана с самим клиентом.

В заключение, ошибка «remote side unexpectedly closed network connection» может быть вызвана разными факторами, включая неправильные настройки, проблемы с сервером SSH, сетевые проблемы и другие. Приведенные выше рекомендации помогут вам попытаться решить эту проблему и продолжить свою работу по удаленному управлению. Если ни одно из этих решений не работает, обратитесь за помощью к системному администратору или провайдеру услуг SSH, чтобы получить более подробную информацию и дополнительную помощь.

I am using Mobaxterm to ssh to customer servers but from a jump host.

The Option which works fine:

when I open mobaxterm —> create a new ssh connection —> enter the hostname (jump host in my case) and username —> and when I try to connect to this session, it works fine and then I need to manually ssh to customer servers after I get connected to jump host.

The Option which does not work:

when I open mobaxterm —> create a new ssh connection —> enter the customer hostname —> under Network setting —> I enable «Connect through SSH gateway (jump host) and enter jump server hostname and username —> save the session.
When I try to connect to this session, it gives error as "Remote side unexpectedly closed network connection".

Can someone assist to solve it.

enter image description here

M123's user avatar

M123

1,2034 gold badges14 silver badges31 bronze badges

asked Oct 11, 2021 at 13:14

Raj Mohata's user avatar

I think you confuse which one to be added as the jump host. As an example, I will use 3.45.67.89 jump host to connect to 192.168.0.100 target host.

Create a new session, and:

  1. Add 192.168.0.100 as your remote host. Specify username and port if necessary.
  2. In Advanced SSH settings tab, check Use private key and insert the credentials for the target host
  3. Go to Network settings tab and configure your jump host by clicking the SSH gateway (jump host) button
  4. Add 3.45.67.89 jump host to one of the jump hosts without forgetting the jump host credentials. Specify username and port.
  5. Click OK and then OK again

If nothing is wrong the SSH connection should work like there’s no jump host.

TLDR; the jump host should be added to SSH gateway (jump host), not as a remote host.

answered Feb 9, 2022 at 12:04

ivan0kurnia's user avatar

  1. Open Mobaxterm
  2. go to Settings menu> click configuration
    dialogue box will appear go to SSH tab in that
  3. In the second Section( SSH Settings) enable the checkbox SSH Keepalive and Fix Connection issues
  4. Click OK to save the configuration.
  5. SSH to the server now !!! enjoy

answered Dec 18, 2021 at 17:26

mishracodes's user avatar

26 мая, 2017 12:02 пп
14 651 views
| Комментариев нет

Linux, SSH, VPS

В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки SSH. Остальные статьи расскажут, как определить и устранить конкретные ошибки:

  • Проблемы с подключением к серверу: здесь вы узнаете, как обнаружить и исправить ошибки подключения к серверу.
  • Ошибки аутентификации: поможет устранить проблемы с парольной аутентификацией или сбросом SSH-ключей.
  • Ошибки оболочки: это руководство поможет исправить ошибки ветвления процессов, валидации оболочки и доступа к домашнему каталогу.

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

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

Требования

  • Убедитесь, что можете подключиться к виртуальному серверу через консоль.
  • Проверьте панель на предмет текущих проблем, влияющих на работу и состояние сервера и гипервизора.

Общие ошибки

Ошибка при проверке ключа хоста

Когда к серверу подключается SSH-клиент, сервер пытается идентифицировать себя с помощью ключа хоста. Если главный ключ изменился, вы можете увидеть такое предупреждение:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
...
В PuTTY предупреждение выглядит так:
WARNING - POTENTIAL SECURITY BREACH!
The server's host key does not match the one PuTTY has
cached in the registry. This means that either the
Server administrator has changed the host key, or you
...

Обычно причиной этой ошибки является:

  • Восстановление сервера с помощью снапшота или резервной копии.
  • Перенос плавающего IP на другой сервер.
  • Переустановка SSH-сервера с помощью менеджера пакетов

Чтобы решить эту проблему, вы можете очистить ключи хоста.

Соединение закрыто или сброшено

Иногда соединения устанавливаются на уровне сокета, но сбрасываются во время проверки ключей хоста. В PuTTY эта ошибка выглядит так:

Server Unexpectedly closed network connection

Клиент OpenSSH выдаёт такую ошибку:

Connection closed by 111.111.111.111 port 22

Эта ошибка, как правило, происходит по следующим причинам:

  • Сбой или ошибки сервиса SSH.
  • Сервис SSH не может инициализировать подключение из-за отсутствия ключей хоста сервера.

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

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

Ошибки переговоров с хостом

При инициировании протокола 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

Источником этой ошибки может быть:

  • Несовпадение реализаций клиента и хоста (если вы используете современный клиент OpenSSH и устаревший хост, последний может просто не поддерживать шифрования клиента).
  • Изменение списка шифрования клиента SSH (возможно, сервер его не поддерживает).

Чтобы решить эту проблему, вам необходимо правильно настроить шифрование на SSH-клиенте.

Устранение неполадок

Сброс ключей известных хостов

Ключи хоста обычно хранятся в файле ~/.ssh/known_hosts клиента OpenSSH. PuTTY обычно хранит их в реестре Windows (HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys).

В PuTTY можно использовать диалоговое окно, чтобы разрешить подключение и обновить реестр (просто выберите Yes). Кроме того, вы можете удалить запись вручную.

На клиенте OpenSSH вы можете найти записи хоста в файле ~/.ssh/known_hosts и удалить их вручную. Также можно использовать команду ssh-keygen.

ssh-keygen -R your_server_ip

Команда попытается получить доступ и очистить соответствующую запись хоста в файле 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 нет собственного закрытого ключа и он не может сгенерировать общий секретный ключ, соединение будет сброшено. Откройте каталог /etc/ssh и попробуйте найти в нём группу файлов с именами sshd_host_*_key. Среди них должен быть файлы с расширением .pub.

Если таких файлов нет, сгенерируйте их с помощью команды ssh-keygen.

ssh-keygen -A

Команда выведет сгенерированные ключи:

ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519

Теперь попробуйте снова подключиться к серверу.

Настройка поддерживаемых шифров SSH

Вы можете настроить поддерживаемые SSH-шифры на клиентской машине, если нужна поддержка устаревшего шифрования (например, SHA1). Это не очень распространенная проблема; обычно она случается, если вы используете новый клиент SSH для подключения к устаревшему SSH-серверу, и они поддерживают разные шифры.

В OpenSSH поддержку SHA1 можно настроить с помощью опции KexAlgorithms. Введите в командную строку:

openssh -oKexAlgorithms=+diffie-hellman-group1-sha1 root@your_server_ip

Клиент PuTTY должен поддерживать группу Диффи-Хеллмана (Connection → SSH → Kex).

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

Tags: OpenSSH, PuTTY, SSH

Понравилась статья? Поделить с друзьями:
  • Renault ошибка df019
  • Renault ошибка df010
  • Remote manipulator system ошибка
  • Renault ошибка c10c3
  • Remote origin already exists git ошибка