Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm really new to solaris and I installed a Solaris 11 Express with all the default options, but I'm having a lot of trouble making an ssh connection.

I am able to connect to the Solaris server through ssh from localhost and from a client that's in the same subnet, but when I try to connect from a client that's on a different subnet (no matter which ssh client I use) I can't. I've tried the ssh client that comes with Debian GNU/Linux 6.0.1, I've tried Secure Shell Client 3.2.9, among others, and no luck. I've even tried installing an other Solaris 11 Express in a virtual machine, doing NAT with the public address in different subnet, and I'm still having the same problem.

Here is the output I receive from the ssh client when I run it with the -vvv option:

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)

And the sshd in the server prints the following when runed with the -ddd option: (last part only)

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)

The file /etc/ssh/sshd_config has the default content, and I read somewhere that adding the line...

GSSAPIAuthentication no

...could help, but it didn't.

I'm afraid it's not a firewall problem either, because I have some other Linux systems in the same network configuration and I'm being able to reach them... in fact, through one of them I can reach the Solaris system by doing double ssh.

Update /etc/ssh/sshd_config has root login enabled

share|improve this question

2 Answers 2

If the problem is only on a different subnet, it's unlikely to be an SSH problem. It's probably the default route setting. Are you using DHCP or a static IP? You can check the default route with "netstat -nr".

share|improve this answer
    
I tried both, and the connection does work, the problem is that it's dropped at some point... look at my answer, it was the ISP. –  andresgallo36 Apr 20 '11 at 18:39
up vote 0 down vote accepted

Well, I looks like it's one of the ISP's fault. I had access to a third subnet and it worked flawlessly... I suppose the SunOS ssh is being blocked at some point when the traffic goes out of the sub network or when it comes from a different one, I even tried using the same IP address and port combination as some of the Linux machines that had the sshd working, and had no change. What made me suspicious was that both ends of the connection reported that the other peer rested the link.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.