Меню

Putty ошибка server unexpectedly closed network connection

26 мая, 2017 12:02 пп
14 071 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

Источник

Содержание

  1. PuTTY Error Fixed: Remote Side Unexpectedly Closed Network Connection
  2. PuTTY Fatal Error: Remote side unexpectedly closed network connection
  3. How to fix the “Remote side unexpectedly closed network connection”error
  4. Bonus tip: Remote into a Windows server without error
  5. Closing words
  6. Устранение неполадок SSH: ошибки протокола
  7. Требования
  8. Общие ошибки
  9. Ошибка при проверке ключа хоста
  10. Соединение закрыто или сброшено
  11. Ошибки переговоров с хостом
  12. Устранение неполадок
  13. Сброс ключей известных хостов
  14. Проверка и генерирование SSH-ключей
  15. Настройка поддерживаемых шифров SSH
  16. Как решить проблему, вылетает ошибка «remote side unexpectedly closed network connection» работая через putty по ssh?

PuTTY Error Fixed: Remote Side Unexpectedly Closed Network Connection

What to do if you failed to connect to your server via SSH using PuTTY and received the “Remote side unexpectedly closed network connection” error? Don’t worry, this post provides you with a solution to fix this problem.

By Ellie / Last Updated December 13, 2022

PuTTY Fatal Error: Remote side unexpectedly closed network connection

“I’m using PuTTY to connect to our server via SSH and immediately receive the following error: Remote side unexpectedly closed network connection. What should I do?”

-Question from StackExchange

How to fix the “Remote side unexpectedly closed network connection”error

When remotely SSH into a server using PuTTY, you may fail and receive the “Remote side unexpectedly closed network connection” error. This is because if a PuTTY session is left idle, it will disconnect at a time set by the host server.

How can you fix the Remote side unexpectedly closed network connection PuTTY? The PuTTY client can be set to connect always and not time out due to inactivity. All you have to do is enable keep-alive in PuTTY. This instructs PuTTY to periodically send null SSH packets to the remote host, preventing the session from timeout.

Step 1. Open PuTTY on the client.

Step 2. Select the Session item. Enter session details such as Hostname or IP Address (e.g., «destination.ipaddress.here.com» or «192.168.1.1»).

Step 3. In the Saved Sessions text-entry box, provide a name for the session (e.g., “savedsession”). Select Save.

Step 4. Choose the Connection option. Change the default value of Seconds between keepalives from (off) to 1800 (30 minutes).

Step5. Check the Enable TCP keepalives (SO KEEPALIVE option).

Note: There are also three things you need to check if you still got the error after configuring the above steps:

  • If the firewall were to block the connection, it would time out. Make sure the firewall is turned off.
  • If the port forwarding is not set up correctly, for example, if you specify the wrong port, it would time out.
  • If you connect to the wrong hostname or IP address, it would time out.

Bonus tip: Remote into a Windows server without error

PuTTY allows you to remotely connect to a server via SSH using commands. However, for users who are not very skilled at commands, using PuTTY is a little bit challenging. Therefore, we would like to recommend you a more intuitive and easy way to achieve remote access. AnyViewer, the free remote access software for Windows, provides you with a GUI experience, helping you achieve remote access with ease.

Besides, it is provided by a strong technical team, helping you complete a stable and fast remote connection. You’ll seldom experience a connection broken down with AnyViewer.

Step 1. On both computers, download, install, and launch AnyViewer. Go to Log in on the Controller computer, and then click Sign up (if you have already signed up on its official website, you can log in directly).

Step 2. Fill out the signup form.

Step 3. You should now see that you have successfully logged into AnyViewer. Your device will be assigned to the account to which you have logged in automatically.

Step 4. Sign in with the same AnyViewer account on both computers, then click the One-click control for unattended remote access.

Step 5. The remote desktop will appear once the connection is established. After that, you have complete control over it.

Notes:вњЋ. It is recommended to upgrade your account to a Professional or Enterprise plan. What can a professional or enterprise plan brings to you: More devices can be assigned to the same account for unattended remote support. Connect in privacy mode to protect your privacy. This means the Controller can black out the remote PC screen and disable the remote keyboard and mouse click. File transfer speed will be increased. Transfer speed is 500 KB/s for a free account and up to 10 MB/s for a paid account.

Closing words

This post primarily introduces how to fix the “Remote side unexpectedly closed network connection” SSH error. The solution is to enable keep-alive in PuTTY. The detailed steps are listed above. If you have encountered this problem, follow the steps to troubleshoot it.

Besides, we also recommend AnyViewer to you. It is a free remote desktop software for Windows. With it, you can easily access a remote server without a connection breakdown.

Источник

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

Источник

Источник

Есть 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 не падал и стабильно работал. Спасибо!

Источник

Перейти к содержанию

На чтение 4 мин Опубликовано 17.07.2018

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

SSHD server unexpectedly closed network connection

Содержание

  1. Журнал ошибок:
  2. Решение №1
  3. Решение №2
  4. Решение №3

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

 # tail -f /var/log/audit/audit.log

type=USER_AUTH msg=audit(1292432614.589:14079): user pid=5965 uid=0 auid=0 ses=1 msg=’op=PAM:authentication acct=”user” exe=”/usr/sbin/sshd” hostname=192.168.1.5 addr=192.168.1.5 terminal=ssh res=success’
type=USER_ACCT msg=audit(1292432614.598:14080): user pid=5965 uid=0 auid=0 ses=1 msg=’op=PAM:accounting acct=”user” exe=”/usr/sbin/sshd” hostname=192.168.1.5 addr=192.168.1.5 terminal=ssh res=failed’
type=USER_LOGIN msg=audit(1292432614.600:14081): user pid=5965 uid=0 auid=0 ses=1 msg=’op=login acct=”user” exe=”/usr/sbin/sshd” hostname=? addr=192.168.1.5 terminal=sshd res=failed’

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

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

Решение №1

Создайте файл

 # touch /etc/environment

Решение №2

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

Решение №3

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

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

 # cd /etc/pam.d
# vim  system-auth-ac

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 < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so

 <b># vim sshd

auth       include      system-auth
account    required     pam_nologin.so
account    include      system-auth
password   include      system-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    include      system-auth
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    optional     pam_keyinit.so force revoke

Пожалуйста, не спамьте и никого не оскорбляйте.

Это поле для комментариев, а не спамбокс.

Рекламные ссылки не индексируются!

Источник

0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии

А вот еще интересные материалы:

  • Яшка сломя голову остановился исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного где ошибка
  • Putty expected key exchange group packet from server ошибка
  • Push уведомления вконтакте ошибка

    • ➤