I'm having a problem with an ssh server "SSH-2.0-Sun_SSH_1.1.2" on solaris 10.
when i do try to connect from windows using puTTY the server refuse's the connection .
when i try to connect using telnet from the same windows machine it accepts the connection and i got the following bannar
SSH-2.0-Sun_SSH_1.1.2
in telnet session
I restarted the ssh with no luck then i rebooted the machine and no luck again ssh accepts connection thru telnet client but not from puTTY also i tried from another machine with same result .
I never had a problem like this before
any ideas would be a great assist.
Thanks
Check your PuTTY settings if you're connecting to the correct port (regular telnet is 23, SSH is 22). Also, if you're able to connect from another machine, can you maybe post a debug output from that connection?
ssh port is set to 22
puTTY output as follows
popup titled
puTTY fatal error
server unexpectedly closed network connection
please ping unix machine from any machine in your network
if you got reply from unix machine IP
please check this file
vi /etc/ssh/sshd_config
you will find some thing like that
# Listen port (the IANA registered port number for ssh is 22)
Port 22
that mean you will connect through port no 22 to configure putty to use this port
if you connect as a regular user every thing will going ok
if you want to connect as root from the first time
open this file
# vi /etc/ssh/sshd_config
and change this value to be yes
PermitRootLogin yes
after you change
you should restart the service of ssh
to find the service do this command
-bash-3.00# svcs -a | grep -i ssh
online Mar_01 svc:/network/ssh:default
to restart the service do this command
-bash-3.00# svcadm restart svc:/network/ssh:default
Note:-
please let us know if it working with you or not
Best Regards
Alexander Corvinus
1- The server is pingable from any host on same subnet or any network
2- The port is set to 22 in sshd_config
3- I restarted the ssh daemon multiple times - ssh accepts connections from a telnet and shows the ssh banner , no luck with puTTY from multiple machines differenet executable for each
4- I restarted the OS - also no luck
Can you ssh locally on the Solaris 10 machine:
ssh localhost
?
If yes, this is more likely a putty issue.
Post the output of :
#svcs | grep ssh
thanks,
Deepak
I can't access the server remotely now because ssh is not accepting connections .
But a workmate said he sshed locally and it works very well.
I'll make sure by myself later when i have access to the server's console .
i am assure the issue is not with putty because i tried multiple fresh putty exes downloaded directly from the offical site on multiple machines
also i tried to ssh from a solaris host with no luck .
the output of
svcs | grep ssh
is as the following
online 11:58:23 svc:/network/ssh:default
the code snippet is sent to me when i and workmate tried to solve the problem
From that other Solaris host, run:
ssh -vvv server
and post the output.
You might also enable temporarily telnet an see if local an remote access work with this simpler protocol:
svcadm enable -t telnet
i sshed from the other solaris host
with the following command
ssh -vvv user@xxx.xxx.xxx.xxx -p 8080
please note : ssh listening port is set to 8080
the following output came out then a promport for password
-bash-3.00$ ssh -vvv user@xxx.xxx.xxx.xxx -p 8080
Sun_SSH_1.1.2, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 8080.
debug1: Connection established.
debug1: identity file /export/home/user/.ssh/identity type -1
debug1: identity file /export/home/user/.ssh/id_rsa type -1
debug1: identity file /export/home/user/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1.2
debug1: match: Sun_SSH_1.1.2 pat Sun_SSH_1.1.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1.2
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,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-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: i-default
debug2: kex_parse_kexinit: i-default
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
Unknown code 0
)
debug1: SSH2_MSG_KEXINIT sent
debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
debug1: SSH2_MSG_KEXINIT received
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,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-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: i-default
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-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: ar-SA,he,he-IL,i-default
debug2: kex_parse_kexinit: ar-SA,he,he-IL,i-default
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: Peer sent proposed langtags, ctos: ar-SA,he,he-IL,i-default
debug1: Peer sent proposed langtags, stoc: ar-SA,he,he-IL,i-default
debug1: We proposed langtags, ctos: i-default
debug1: We proposed langtags, stoc: i-default
debug1: Negotiated lang: i-default
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: Remote: Negotiated main locale: C
debug1: Remote: Negotiated messages locale: C
debug1: dh_gen_key: priv key bits set: 133/256
debug1: bits set: 1617/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /export/home/user/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 3
debug1: Host 'xxx.xxx.xxx.xxx' is known and matches the RSA host key.
debug1: Found key in /export/home/user/.ssh/known_hosts:3
debug1: bits set: 1579/3191
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
debug1: newkeys: mode 1
debug1: set_newkeys: setting new keys for 'out' mode
debug3: aes-128-ctr NID found
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: set_newkeys: setting new keys for 'in' mode
debug3: aes-128-ctr NID found
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug2: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug3: start over, passed a different list gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /export/home/user/.ssh/identity
debug3: no such identity: /export/home/user/.ssh/identity
debug1: Trying private key: /export/home/user/.ssh/id_rsa
debug3: no such identity: /export/home/user/.ssh/id_rsa
debug1: Trying private key: /export/home/user/.ssh/id_dsa
debug3: no such identity: /export/home/user/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
i supplied an incorrect password for testing the output came out as follows
Password:
debug3: packet_send2: adding 32 (len 17 padlen 15 extra_pad 64)
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
and again a prompet to re enter password
Password:
debug3: packet_send2: adding 32 (len 17 padlen 15 extra_pad 64)
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
after fewer tries for some reason the the server now accepts connection from solaris host within same subnet i tried putty on a machine on same subnet with no luck
what other procedures should i take to fix the problem
So it works as expected. Supplying an incorrect password doesn't log you in. You previously wrote "also i tried to ssh from a solaris host with no luck ." Please clarify.
It wasn't working at all from that solaris host , suddenly for unknown reason it's working from that solaris host , but the problem still exist it doesn't accept connections from putty from hosts on same subnet it's also not accepting connections remotely .
are there any other procedures should i take to fix the problem
thanks
Please find a Solaris host where the problem shows up and run again the verbose ssh command.
i sshed from a remote solaris host not within same subnet and it accepts connections
i used the following command
ssh -v user@xxx.xxx.xxx.xxx -p 8080
prompted for the password and i supplied the correct password the login was successful
and the output came as the following
bash-3.00# ssh -v user@xxx.xxx.xxx.xxx -p 8080
Sun_SSH_1.1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
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 xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 8080.
debug1: Connection established.
debug1: identity file /.ssh/identity type -1
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1.2
debug1: match: Sun_SSH_1.1.2 pat Sun_SSH_1.1*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1.1
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
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
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: Peer sent proposed langtags, ctos: ar-SA,he,he-IL,i-default
debug1: Peer sent proposed langtags, stoc: ar-SA,he,he-IL,i-default
debug1: We proposed langtags, ctos: i-default
debug1: We proposed langtags, stoc: i-default
debug1: Negotiated lang: i-default
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: Remote: Negotiated main locale: C
debug1: Remote: Negotiated messages locale: C
debug1: dh_gen_key: priv key bits set: 143/256
debug1: bits set: 1648/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'xxx.xxx.xxx.xxx' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:4
debug1: bits set: 1570/3191
debug1: ssh_rsa_verify: signature correct
debug1: newkeys: mode 1
debug1: set_newkeys: setting new keys for 'out' mode
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: set_newkeys: setting new keys for 'in' mode
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug1: Next authentication method: gssapi-with-mic
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: Next authentication method: publickey
debug1: Trying private key: /.ssh/identity
debug1: Trying private key: /.ssh/id_rsa
debug1: Trying private key: /.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive)
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 0
debug1: channel request 0: env
debug1: channel request 0: pty-req
debug1: channel request 0: shell
debug1: fd 4 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug1: Remote: Channel 0 set: LANG=C
Last login: Fri Mar 5 01:27:57 2010 from xxx.xxx.xxx.xxx
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
-bash-3.00$
connecting from a remote or local windows host with putty fails .
strange isn't it
Not strange at all to me. All your tests show ssh works as expected from and to Solaris machines.
Putty is then likely to blame. Are you sure to use the very latest version ? Any error log on the putty side ?
putty used is the current verison on the official site .
I download fresh copy of putty on each machine which are restarted daily .
So perhaps was the issue either introduced with a recent putty release or is a networking one (firewall, routing, duplicate address, name resolution, whatever).
I always use putty this release all days and nights which is stable and sufficient from my humble point of view
I did an md5 checksum check to make sure the binary is intact the check was successful always
Maybe the problem is as you suggest (firewall, routing, duplicate address, name resolution, whatever).
i give up .
I have just had a similar problem but with Solaris 9.
Unix to Solaris no problem.
Windows clients using SSH to Solaris failing
Performed all the same checks just as other members have suggested in this thread.
Finally our only option was to attempt a re-install of SSH.
Downloaded OpenSSH along with all the requisite supporting packages from Sunfreeware. Installed them, made the required config changes and bingo!
SSH access is now behaving as it should. Happy days!
Thanks for your tip