Назад | Перейти на главную страницу

SSH: сброс подключения одноранговым узлом

У меня есть сервер Solaris 10 в другой сети. Я могу пинговать его и подключаться к нему через Telnet, но ssh не подключается. Журнал PuTTY не содержит ничего интересного (они оба ведут переговоры с ssh v2), а затем я получаю

"Event Log: Network error: Software caused connection abort".

ssh определенно запущен:

svcs -a | grep ssh
online         12:12:04 svc:/network/ssh:default

Вот выдержка из / var / adm / messages сервера (анонимно)

Jun  8 19:51:05 ******* sshd[26391]: [ID 800047 auth.crit] fatal: Read from socket failed: Connection reset by peer

Однако, если я подключусь к коробке через telnet, я могу войти в ssh локально. Я также могу использовать ssh для других (не Solaris) компьютеров в этой сети, поэтому я не верю, что это проблема сети (хотя, поскольку я нахожусь в нескольких сотнях миль, я не могу быть уверен).

Брандмауэр сервера отключен, так что проблем быть не должно.

root@******** # svcs -a | grep -i ipf
disabled       Apr_27   svc:/network/ipfilter:default

Есть идеи, что мне начать проверять?

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

$ ssh -vvv root@machine -p 32222
OpenSSH_5.0p1, OpenSSL 0.9.8h 28 May 2008
debug2: ssh_connect: needpriv 0
debug1: Connecting to machine [X.X.X.X] port 32222.
debug1: Connection established.
debug1: identity file /home/lawrencj/.ssh/identity type -1
debug1: identity file /home/lawrencj/.ssh/id_rsa type -1
debug1: identity file /home/lawrencj/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1
debug1: no match: Sun_SSH_1.1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.0
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer

А вот вывод сервера:

root@machine # /usr/lib/ssh/sshd -d -p 32222
debug1: sshd version Sun_SSH_1.1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: Bind to port 32222 on ::.
Server listening on :: port 32222.
debug1: Bind to port 32222 on 0.0.0.0.
Server listening on 0.0.0.0 port 32222.
debug1: Server will not fork when running in debugging mode.
Connection from 1.2.3.4 port 2652
debug1: Client protocol version 2.0; client software version OpenSSH_5.0
debug1: match: OpenSSH_5.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer
debug1: Calling cleanup 0x4584c(0x0)

Эта строка кажется вероятным кандидатом:

debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible

Проверьте свой файл .ssh / authorized_keys на сервере, если вы используете аутентификацию на основе ключей. У меня была такая же проблема, и человек, который установил доступ, вставил ключ с разрывами строки. Удаление разрывов строк устранило проблему, хотя вы можете проверить, переместив файл authorized_keys в сторону или выбрав аутентификацию по паролю сначала и посмотрите, возникнет ли у вас такая же проблема:

ssh -o PreferredAuthentications=password username@hostname

Попробуйте полностью отключить GSSAPI:

GSSAPIAuthentication no

Вы в списке разрешенных пользователей в sshd_config?

Возможно, вы сможете получить более полезную отладочную информацию, выполнив sshd с -d флаг (и, возможно, -p флаг, чтобы указать другой порт, если вы хотите оставить исходный sshd работает), а затем подключиться к нему с помощью ssh -v клиент.

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

Это интересно, у меня такая же проблема. Только я могу использовать ssh из локальной сети, но не при использовании vpn.

11 мая 18:03:10 имя сервера sshd [14733]: [ID 800047 auth.crit] фатальный: Ошибка чтения из сокета: сброс соединения одноранговым узлом

Мне никогда не предлагается ввести пароль. Сессии умирают быстро.

Я подозревал, что это связано с проблемами обмена ключами, поскольку вы говорите, что SSHv2 согласован.

Пока не удалось найти подходящего описания; есть эта ссылка на PuTTY хотя.

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

Вы также можете попробовать "ssh -v«чтобы увидеть, какие ошибки видит клиент.

В 99% случаев это вызвано TCP Wrappers (hosts.deny). Вероятно, вам нужно разрешить здесь свой IP-адрес:

/etc/hosts.deny

Причина, по которой он работает с localhost, заключается в том, что 127.0.0.1, вероятно, разрешен там (или через /etc/hosts.allow).

Ваш sshd разветвляется для обработки соединения (даже при отладке). Мне кажется, что ребенок тихо умирает, как только он собирается взаимодействовать с механизмами аутентификации системы. Это примерно то время, когда он обычно проверяет UID, GID и запускает PAM. Ваш сервер использует LDAP или NIS +?

Лучше всего запустить отладку на правильно работающем сервере и посмотреть, что будет дальше (используйте vimdiff или diff).

У меня недавно возникла очень похожая проблема, когда в группе было слишком много участников (длина всех участников составляла около 500-600 символов). Хотя это было в Linux.

Замечание: при запуске сервера для отладки укажите -ddd (тройная отладка), чтобы получить дополнительную информацию.

Вы говорите, что целевой хост находится в другой сети. И что «брандмауэр серверов отключен».

Есть ли между вашей сетью и сетью назначения брандмауэр или какое-либо устройство фильтрации пакетов.

Стоит провести трассировку, чтобы увидеть, что находится между двумя сетями.

Также убедитесь, что вы не теряете пакеты во время передачи. Простой тест с помощью команды ping может помочь вам выяснить, есть ли у вас проблемы с сетью.

В моем случае просмотр / var / log / messages показал, что у меня открыто слишком много сеансов (ограничено PAM): 21 августа 18:05:43 nv20 pam_limits [13325]: слишком много входов в систему (максимум 20) для пользователя

Через несколько ctrl-D и ssh снова заработал ...

Я только что решил аналогичную проблему с тем же симптомом: отключено после:

debug1: SSH2_MSG_KEXINIT sent.

Запуск ssh-сервера на двух портах, 22 и «еще один нераскрытый порт». Я мог подключиться через порт 22, но не использовать другой порт с указанным выше внезапным отключением перед обменом ключами хоста.

Оказалось, что sshd для порта 22 работал как корень пока sshd для другого порта он был запущен как пользователь убунту. Очевидно, что пользователь ubuntu не может не прочитать закрытый ключ хоста, как показано на /var/log/auth.log:

error: Could not load host key: /etc/ssh/ssh_host_rsa_key
error: Could not load host key: /etc/ssh/ssh_host_dsa_key
fatal: No supported key exchange algorithms

Команда 'sudo netstat -nap | grep ssh ' вернул 2 разных процесса для порта 22 и другого порта (отредактировано):

$ sudo netstat -nap | grep ssh
tcp        0      0 0.0.0.0:other port      0.0.0.0:*               LISTEN      17620/sshd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      31160/sshd
tcp6       0      0 :::other port           :::*                    LISTEN      17620/sshd
tcp6       0      0 :::22                   :::*                    LISTEN      31160/sshd

Показывает, что сервер ssh на порту 22 использует процесс #31160 в то время как другой порт использует порт #17620.

И пс-лист | grep ssh 'показал, что один процесс выполнялся как root, а другой - как ubuntu (отредактировано):

$ ps -eaf | grep ssh
ubuntu   17620     1  0 Apr25 ?        00:00:00 /usr/sbin/sshd
root     31160     1  0 08:35 ?        00:00:00 /usr/sbin/sshd

Чтобы решить проблему, мне пришлось убить процесс, работающий как ubuntu (убить 17620) и перезапустите ssh-сервер с помощью команды 'sudo /etc/init.d/ssh перезапуск'.

Я не знаю точно, как это произошло, но после попытки воспроизвести проблему я обнаружил, что мог попытаться перезапустить sshd, не будучи root. Он работает, но новый порт размещен пользователем ubuntu:

$ /etc/init.d/ssh restart
Could not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
 * Restarting OpenBSD Secure Shell server sshd
start-stop-daemon: warning: failed to kill 31884: Operation not permitted
Could not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key

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

Тем, кому интересно, я использую другой порт вместо порта 22, чтобы предотвратить большинство попыток подключения к порту 22 на всех моих серверах, а затем блокирую порт 22 с помощью брандмауэра. Это просто, но работает и позволяет мне подключаться с любого IP-адреса.

Эту проблему можно решить, выполнив следующие 2 команды из командной строки консоли / терминала на машине, к которой шпатлевка не может получить доступ:

$ sudo apt-get --purge удалить openssh-server
$ sudo apt-get install openssh-server

Первая команда полностью удаляет сервер openssh с помощью очистки, в отличие от autoremove, при котором файлы конфигурации остаются. Вторая команда переустанавливает опнеш сервер

Теперь попробуйте снова войти в машину.