Я действительно новичок в Solaris, и я установил Solaris 11 Express со всеми параметрами по умолчанию, но у меня много проблем с установкой ssh-соединения.
Я могу подключиться к серверу Solaris через ssh с localhost и с клиента, который находится в той же подсети, но когда я пытаюсь подключиться с клиента, который находится в другой подсети (независимо от того, какой ssh-клиент я использую), я не могу . Я пробовал ssh-клиент, который поставляется с Debian GNU / Linux 6.0.1, я пробовал Secure Shell Client 3.2.9, среди прочего, и не повезло. Я даже пытался установить другой Solaris 11 Express на виртуальную машину, выполняя NAT с публичным адресом в другой подсети, и у меня все еще та же проблема.
Вот результат, который я получаю от клиента ssh, когда запускаю его с параметром -vvv:
andres@solaris1:~$ ssh root@<ip-address> -p <port> -vvv
Sun_SSH_1.5, SSH protocols 1.5/2.0, OpenSSL 0x009080ff
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to <ip-address> [<ip-address>] port <port>.
debug1: Connection established.
debug1: identity file /home/andres/.ssh/identity type -1
debug1: identity file /home/andres/.ssh/id_rsa type -1
debug1: identity file /home/andres/.ssh/id_dsa type -1
debug1: Logging to host: <ip-address>
debug1: Local user: andres Remote user: root
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.5
debug1: match: Sun_SSH_1.5 pat Sun_SSH_1.5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.5
debug1: use_engine is 'yes'
debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers
debug1: pkcs11 engine initialization complete
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: en-US
debug2: kex_parse_kexinit: en-US
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
)
debug1: SSH2_MSG_KEXINIT sent
debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
Read from socket failed: Connection reset by peer
debug1: Calling cleanup 0x8079eb0(0x0)
И sshd на сервере при запуске с параметром -ddd выводит следующее: (только последняя часть)
debug1: We proposed langtags, stoc: af-ZA,ar-EG,as-IN,az-AZ,be-BY,bg-BG,bn-IN,bs-BA,ca-ES,cs-CZ,da-DK,de-DE,el-GR,en-US,es-ES,et-EE,fi-FI,fr-FR,gu-IN,he-IL,hi-IN,hr-HR,hu-HU,hy-AM,id-ID,is-IS,it-IT,ja-JP,ka-GE,kk-KZ,kn-IN,ko-KR,ks-IN,ku-TR,ky-KG,lt-LT,lv-LV,mk-MK,ml-IN,mr-IN,ms-MY,mt-MT,nb-NO,nl-NL,nn-NO,or-IN,pa-IN,pl-PL,pt-BR,pt-PT,ro-RO,ru-RU,sa-IN,sk-SK,sl-SI,sq-AL,sr-RS,sv-SE,th-TH,tr-TR,uk-UA,vi-VN,zh-CN,i-default,zh-TW
debug1: Negotiated main locale: en_US.UTF-8
debug1: Negotiated messages locale: en_US.UTF-8
Write failed: Broken pipe
debug1: Calling cleanup 0x808bc80(0x0)
monitor debug1: child closed the communication pipe before user auth was finished
monitor debug1: Calling cleanup 0x808bc80(0x0)
monitor debug1: Calling cleanup 0x808bc80(0x0)
Файл / etc / ssh / sshd_config имеет содержимое по умолчанию, и я где-то читал, что добавляет строку ...
GSSAPIAuthentication no
... может помочь, но не помогло.
Боюсь, это не проблема брандмауэра, потому что у меня есть несколько других систем Linux в той же сетевой конфигурации, и я могу связаться с ними ... на самом деле, через одну из них я могу связаться с системой Solaris, выполнив двойной ssh.
Обновить В / etc / ssh / sshd_config включен вход root
Если проблема только в другой подсети, это вряд ли проблема SSH. Вероятно, это настройка маршрута по умолчанию. Вы используете DHCP или статический IP? Вы можете проверить маршрут по умолчанию с помощью "netstat -nr".
Ну, похоже, это одна из ошибок провайдера. У меня был доступ к третьей подсети, и она работала безупречно ... Я полагаю, что SunOS ssh блокируется в какой-то момент, когда трафик выходит из подсети или когда он идет из другой, я даже пытался использовать тот же IP комбинация адреса и порта, как на некоторых машинах Linux, на которых работает sshd, но без изменений. Что заставило меня подозревать, так это то, что оба конца соединения сообщили, что другой одноранговый узел оставил ссылку.