Remote side unexpectedly closed network connection windows
Проблема с правами доступа
via google://rpm restore permissions
это в терминале прописать?
Конечно, а какие еще есть варианты?
rmp и via команды не найдены
а если rpm (прочитай внимательно)!
«via google» значит «погугли» или «из Google» и потом запрос идет.
От root’а выполняешь?
что то я разнервничился, погуглил нашёл кое что потом отпишусь, спасибо ребят что хоть отзываетесь
кстати у меня сейчас под рутом не заходит,через логин админ захожу! я нуб в линуксе дружище пойми!
А откуда у вас сервак то завелся?
но к сожалению всё тщетно, доступ по SSh так и не появился клиент выдаёт ту же ошибку
Ну как минимум это от рута нужно делать. Чтоб залогиниться рутом после логина под своей учеткой либо su и после запроса вводишь пароль root’а, либо sudo su и свой пароль.
А вообще конфиги sshd не менял?
«Server unexpectedly closed network connection»
Это, кстати, при логине от root или вообще при любой учетке при логине?
конфиги sshd не менял!а как это сделать?
Открыть файл /etc/ssh/sshd_config Добавить PermitRootLogin yes
Где остальные каталоги?
кстати ошибку «Server unexpectedly closed network connection» клиент выдаёт сразу не запрашивая даже логин и пароль, что делать не знаю уже весь инет облазил
это стоит вообще сейчас прописывать и как..рекурсивно права задавать
Я смысла не вижу. Внутри этих папок файлы с другими правами тоже есть.
Посмотри логи sshd, вроде /var/log/auth.log
такого в логах нет почему то, беда ребят где нибудь ещё можно посмотреть возникающие ошибки на тему SSH
/etc/ssh/sshd_config может вся проблема здесь
всё сделал но открыть не получается
Раз у тебя есть локальная консоль сервера:
И смотри debug вывод в консоли. Будут жалобы — исправляй.
в общем ругается на какой то приватный ключ, только вот что с ним делать.попробую разобраться,в общем вот что получилось
debug1: sshd version OpenSSH_4.3p2 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0777 for ‘/etc/ssh/ssh_host_rsa_key’ are too open. It is recommended that your private key files are NOT accessible by others. This private key will be ignored. bad permissions: ignore key: /etc/ssh/ssh_host_rsa_key Could not load host key: /etc/ssh/ssh_host_rsa_key @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0777 for ‘/etc/ssh/ssh_host_dsa_key’ are too open. It is recommended that your private key files are NOT accessible by others. This private key will be ignored. bad permissions: ignore key: /etc/ssh/ssh_host_dsa_key Could not load host key: /etc/ssh/ssh_host_dsa_key Disabling protocol version 2. Could not load host key sshd: no hostkeys available — exiting.
Permissions 0777 for ‘/etc/ssh/ssh_host_rsa_key are too open
Permissions 0777 for ‘/etc/ssh/ssh_host_dsa_key are too open
Как решить проблему, вылетает ошибка «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 ssh status, ssh не рабочий(:
Помогает команда sudo /etc/init.d/ssh restart
После этой команды, вроде все норм:
Если докер перегрузить, сервер работает, но после первого подключения по 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 не падал и стабильно работал. Спасибо!
Как решить проблему, вылетает ошибка “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-клиент, сервер пытается идентифицировать себя с помощью ключа хоста. Если главный ключ изменился, вы можете увидеть такое предупреждение:
Обычно причиной этой ошибки является:
Чтобы решить эту проблему, вы можете очистить ключи хоста.
Соединение закрыто или сброшено
Иногда соединения устанавливаются на уровне сокета, но сбрасываются во время проверки ключей хоста. В 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, вы можете обратиться за помощью к службе поддержки своего хостинг-провайдера.
SFTP «Remote side unexpectedly closed network connection» when session had succeeded
SFTP «Remote side unexpectedly closed network connection» when session had succeeded
I’ve recently had this problem crop up with one of my SFTP partners I’ve been using for several months. This issue appears to have happened a few times in those several months but is now possibly increasing in frequency.
I had the partner dig out SFTP server logs from their side when this happened last week and we reviewed them. One session where this below same issue happened had *server* logs (their side) that looked identical to other successful transfers where I saw no problem on the WinSCP side, so there doesn’t seem to be much to trace on their side.
The command I ran was:
And you can see that at the very end, once the file has successfully been full uploaded and WinSCP has announced beginning the disconnect, we get a remote side closed message which of course causes the whole WinSCP command to fail with exit code 1, which forces me to have to review the situation.
Any idea what might be causing this and whether there’s an existing safe way that I could work around this in my scripting so that in situations like these (where there was some weird problem at the *very* end, but after all of the critical scripting actions completed successfully), I could somehow end up with a exit code 0 (short of having to parse the log file output and concluding that the transfer did actually work)?
I’m aware of this thread:
which seems to address a problem in the SFTP server OpenSSH version having to do with WinSCP version strings. Would that explain why I only *occasionally* have this problem with this partner server though? I mean it’s something like 1 out of 20 or 30 transfers (maybe even less frequent) that this happens.
Here’s the tail of the log:
Re: SFTP «Remote side unexpectedly closed network connection» when session had succeeded
tgice Joined: 2015-06-25 Posts: 5
Hi Martin, thanks for your reply.
Do you think this debug version might solve my problem or just provide better logging for analysis?
If it’s the latter, what log settings do you recommend? I assume you’d want the /log= option again and the highest loglevel?
Hi Martin, I finally think I’ve captured a good debug trace of this event happening.
Could you email me about a private method of submitting them to you?
You can post new topics in this forum