Sou muito novo no solaris e instalei um Solaris 11 Express com todas as opções padrão, mas estou tendo muitos problemas para fazer uma conexão ssh.
Eu consigo me conectar ao servidor Solaris por meio do ssh de localhost e de um cliente que está na mesma sub-rede, mas quando tento conectar de um cliente que está em uma sub-rede diferente (não importa qual cliente ssh eu use) não pode. Eu tentei o cliente ssh que vem com o Debian GNU / Linux 6.0.1, eu tentei o Secure Shell Client 3.2.9, entre outros, e sem sorte. Eu até tentei instalar um outro Solaris 11 Express em uma máquina virtual, fazendo NAT com o endereço público em uma sub-rede diferente, e ainda estou tendo o mesmo problema.
Aqui está a saída que recebo do cliente ssh quando eu o executo com a opção -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)
E o sshd no servidor imprime o seguinte quando executado com a opção -ddd: (última parte apenas)
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)
O arquivo / etc / ssh / sshd_config tem o conteúdo padrão, e eu li em algum lugar que adicionar a linha ...
GSSAPIAuthentication no
... poderia ajudar, mas não ajudou.
Eu tenho medo de que não seja um problema de firewall, porque eu tenho alguns outros sistemas Linux na mesma configuração de rede e estou conseguindo alcançá-los ... na verdade, através de um deles eu posso alcançar o Solaris sistema fazendo duplo ssh.
Atualizar / etc / ssh / sshd_config tem login de root ativado
Bem, parece que é uma das falhas do ISP. Eu tive acesso a uma terceira sub-rede e funcionou perfeitamente ... Suponho que o SunOS ssh está sendo bloqueado em algum momento quando o tráfego sai da sub-rede ou quando vem de um diferente, eu até tentei usar o mesmo IP endereço e combinação de portas como algumas das máquinas Linux que tinham o sshd funcionando e não tinham nenhuma mudança. O que me fez suspeitar foi que ambas as extremidades da conexão relataram que o outro par estava no link.
Se o problema for apenas em uma sub-rede diferente, é improvável que seja um problema de SSH. É provavelmente a configuração de rota padrão. Você está usando DHCP ou um IP estático? Você pode verificar a rota padrão com "netstat -nr".