Putty fatal error remote side unexpectedly closed network connection

Устранение неполадок SSH: ошибки протокола

В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки 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_USERSoftwareSimonTathamPuTTYSshHostKeys).

В 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: 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, вы можете обратиться за помощью к службе поддержки своего хостинг-провайдера.

Источник

Как решить проблему, вылетает ошибка «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 все повторяется:-(

Вывод команды #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 не падал и стабильно работал. Спасибо!

Источник

SSH connection failure: Server unexpectedly closed network connection

Question & Answer

Question

SSH connection failure: Server unexpectedly closed network connection

Answer

Issue

You may come across the following error message in the Aspera transfer log:

SSH connection failure: Server unexpectedly closed network connection

One of the most common causes of this error is the MaxStartups setting in the server’s sshd_config file:

• Linux: /etc/ssh/sshd_config
• Windows: C:Program Files[(x86)]Aspera[Aspera Product]etcsshd_config

(The # in the sshd_config signifies the default).

These limit the number of unauthenticated SSH connections attempts to 10 (in the case of Windows they start failing 30% of the time with 10 increasing to 100% at 60). In high concurrency environments these values may be too low (especially if SSH is using TCP port 22 instead of the recommended TCP port 33001).

Environment

• Product: Any
• Operating System: Linux Windows

Solution

We recommend changing theMaxStartups entry to 100:

This would be the recommended setting on both Linux and Windows. (Notice no # sign). Some customers in extremely high concurrency environments have increased this value to 500.

After this change the SSHD process must be restarted for it to take effect:

Источник

SSH-сервер неожиданно закрыл интернет соединение

При подключении сервера Linux через шпаклеру произошла ошибка:

SSHD server unexpectedly closed network connection

Журнал ошибок:

Может быть несколько причин для ошибки.

Попробуйте следующие методы устранения проблем.

Решение №1

Решение №2

Проверьте файл /etc/hosts.deny на блокировку вашего ip / host.

Решение №3

Проверьте метод аутентификации.

После изменения настроек pam.d ssh начал работать.

auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_ldap.so use_first_pass
auth sufficient pam_smb_auth.so use_first_pass nolocal
auth required pam_deny.so

account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid

• Аудит ИБ (49)
• Вакансии (12)
• Закрытие уязвимостей (105)
• Книги (27)
• Мануал (2 218)
• Медиа (66)
• Мероприятия (39)
• Мошенники (23)
• Обзоры (797)
• Обход запретов (34)
• Опросы (3)
• Скрипты (108)
• Статьи (334)
• Философия (90)
• Юмор (18)

Anything in here will be replaced on browsers that support the canvas element

Источник

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.

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

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.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

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.

why can’t i connect to droplet?

Try DigitalOcean for free

Click below to sign up and get $200 of credit to try our products over 60 days!

Popular Topics

Questions

Sign up for Infrastructure as a Newsletter.

Working on improving health and education, reducing inequality, and spurring economic growth? We’d like to help.

You get paid; we donate to tech nonprofits.

Welcome to the developer cloud

DigitalOcean makes it simple to launch in the cloud and scale up as you grow – whether you’re running one virtual machine or ten thousand.

Источник

Есть 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 все повторяется:-(

Вывод команды #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 не падал и стабильно работал. Спасибо!

Does this error occur while you are connecting to your instance? If yes, then don’t worry, we will help you resolve it. Read this blog to know how you can resolve this error like a pro!

If you are connecting to your instance with Putty and receive the error “Server unexpectedly closed network connection”, then you can resolve it with two solutions and we are going to discuss these two solutions in this blog.

This is the error –

If this error message appears, there is possibility that

1. You are not using the correct username when connecting to your instance
2. You are not using the correct key when connecting to your instance”
3. PuTTy options –> Connection problem
4. You have accidentally applied Chmod 777 on the root folder

Since it might be an SSH issue, we have found the following link on troubleshooting problems which will help you in connecting to your instance: https://aws.amazon.com/premiumsupport/knowledge-center/ec2-linux-ssh-troubleshooting/

You can try connecting again by entering your correct username because it is possible that you entered the wrong username before. Try this and see if it works.

Just like this, try connecting again by entering the correct key and see if it works.

If both of these don’t work, then you need to try these two solutions for connecting to your instance. Let’s see what these solutions are and how they work.

SOLUTIONS 1

Here is the first solution for you that can help you resolve this error

Go to PuTTy options –> Connection

1. Change the default value for “Seconds between keepalives(0 to turn off)”: from 0 to 600 (10 minutes) — in my case taking 30 seconds That means it sends a “ping” every 30 seconds to prevent the connection from timing out
2. Check the “Enable TCP_keepalives (SO_KEEPALIVE option)” check box.
3. Finally, save the setting for the session

Youtube Video – https://www.youtube.com/watch?v=cFP4AsxvwNQ&feature=youtu.be

SOLUTIONS 2

Here is the 2nd solution to resolve this error

It might be possible that you have put Chmod 777 to remove chmod 777 permission on the root folder.

If you just want to remove the write permission to others, the command is given below and it has to be done from the root folder: chmod o-w /

This will remove others’ permission from / (root folder)

* o means others. * w means write permissions.

So o-w means remove written permission from others. You can also read online to know how this exactly works and how the permissions can be updated for Linux.

Here are some of the references to Forums and documents:

— https://forums.aws.amazon.com/thread.jspa?threadID=60938 — https://forums.aws.amazon.com/thread.jspa?threadID=212950 — https://forums.aws.amazon.com/thread.jspa?threadID=56946

Whenever the such error appears, these two solutions can be helpful for you to resolve the error and you will able to connect to your instance easily. So, if you come across this error, follow these two solutions and say goodbye to the error in a few minutes.

We hope you resolve this error successfully with the help of this blog. (Metizsoft Solutions Private Limited)

Read More:

How to disable TLS 1.0 in the windows server?

26 мая, 2017 12:02 пп
14 164 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_USERSoftwareSimonTathamPuTTYSshHostKeys).

В 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