Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Sep 2006 23:50:22 +0900
From:      Garrett Cooper <youshi10@u.washington.edu>
To:        freebsd-questions@freebsd.org
Subject:   Re: PAY offered - sshd won't allow client from same domain
Message-ID:  <0B046E68-80D8-4A75-9D4F-354122F7B75F@u.washington.edu>
In-Reply-To: <54DA4AB7-ACD4-4C04-95FD-CB1A21692AE9@u.washington.edu>
References:  <B65B3EC5-1D8D-46AB-847F-E31034158868@redstarling.com> <A27A8BC0-D31D-428E-B917-578A1AA4A3A6@u.washington.edu> <F76E2B6D-6318-4A61-BC72-4CD974AF92DB@redstarling.com> <54DA4AB7-ACD4-4C04-95FD-CB1A21692AE9@u.washington.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 16, 2006, at 10:51 PM, Garrett Cooper wrote:

> On Sep 16, 2006, at 6:05 PM, ke han wrote:
>
>>
>> On Sep 16, 2006, at 4:50 PM, Garrett Cooper wrote:
>>
>>> ssh -vv server1.domain.com
>>
>> form OS X:  (real domain name edited to domain.com)
>>
>> > ssh -vv server1.domain.com
>> OpenSSH_4.2p1, OpenSSL 0.9.7i 14 Oct 2005
>> debug1: Reading configuration data /etc/ssh_config
>> debug2: ssh_connect: needpriv 0
>> debug1: Connecting to server1.domain.com [209.216.230.199] port 22.
>> debug1: Connection established.
>> debug1: identity file /Users/jhancock/.ssh/identity type -1
>> debug1: identity file /Users/jhancock/.ssh/id_rsa type -1
>> debug2: key_type_from_name: unknown key type '-----BEGIN'
>> debug2: key_type_from_name: unknown key type 'Proc-Type:'
>> debug2: key_type_from_name: unknown key type 'DEK-Info:'
>> debug2: key_type_from_name: unknown key type '-----END'
>> debug1: identity file /Users/jhancock/.ssh/id_dsa type 2
>> debug1: Remote protocol version 2.0, remote software version  
>> OpenSSH_4.2p1 FreeBSD-20050903
>> debug1: match: OpenSSH_4.2p1 FreeBSD-20050903 pat OpenSSH*
>> debug1: Enabling compatibility mode for protocol 2.0
>> debug1: Local version string SSH-2.0-OpenSSH_4.2
>> debug2: fd 3 setting O_NONBLOCK
>> debug1: Miscellaneous failure
>> No credentials cache found
>>
>> debug1: Miscellaneous failure
>> No credentials cache found
>>
>> debug1: SSH2_MSG_KEXINIT sent
>> debug1: SSH2_MSG_KEXINIT received
>> debug2: kex_parse_kexinit: diffie-hellman-group-exchange- 
>> sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
>> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
>> debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish- 
>> cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256- 
>> cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
>> debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish- 
>> cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256- 
>> cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
>> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- 
>> ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
>> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- 
>> ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
>> debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
>> debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
>> debug2: kex_parse_kexinit:
>> debug2: kex_parse_kexinit:
>> debug2: kex_parse_kexinit: first_kex_follows 0
>> debug2: kex_parse_kexinit: reserved 0
>> debug2: kex_parse_kexinit: diffie-hellman-group-exchange- 
>> sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
>> debug2: kex_parse_kexinit: ssh-dss
>> debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish- 
>> cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256- 
>> cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
>> debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish- 
>> cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256- 
>> cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
>> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- 
>> ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
>> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- 
>> ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
>> debug2: kex_parse_kexinit: none,zlib@openssh.com
>> debug2: kex_parse_kexinit: none,zlib@openssh.com
>> debug2: kex_parse_kexinit:
>> debug2: kex_parse_kexinit:
>> 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-cbc hmac-md5 none
>> debug2: mac_init: found hmac-md5
>> debug1: kex: client->server aes128-cbc hmac-md5 none
>> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
>> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
>> debug2: dh_gen_key: priv key bits set: 132/256
>> debug2: bits set: 523/1024
>> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
>> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
>> debug1: Host 'server1.domain.com' is known and matches the DSA  
>> host key.
>> debug1: Found key in /Users/jhancock/.ssh/known_hosts:2
>> debug2: bits set: 527/1024
>> debug1: ssh_dss_verify: signature correct
>> debug2: kex_derive_keys
>> debug2: set_newkeys: mode 1
>> debug1: SSH2_MSG_NEWKEYS sent
>> debug1: expecting SSH2_MSG_NEWKEYS
>> debug2: set_newkeys: mode 0
>> debug1: SSH2_MSG_NEWKEYS received
>> debug1: SSH2_MSG_SERVICE_REQUEST sent
>> Read from socket failed: Connection reset by peer
>
> Your problem appears to be in how your user is being authenticated  
> and not your DNS setup, I think. Example:
>
> shiina:~ gcooper$ uname -a
> Darwin shiina.local 8.7.0 Darwin Kernel Version 8.7.0: Fri May 26  
> 15:20:53 PDT 2006; root:xnu-792.6.76.obj~1/RELEASE_PPC Power  
> Macintosh powerpc
> shiina:~ gcooper$ ssh -vv tebo.cs.washington.edu
> OpenSSH_4.2p1, OpenSSL 0.9.7i 14 Oct 2005
> debug1: Reading configuration data /etc/ssh_config
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to tebo.cs.washington.edu [128.208.6.74] port 22.
> debug1: Connection established.
> debug1: identity file /Users/gcooper/.ssh/identity type -1
> debug2: key_type_from_name: unknown key type '-----BEGIN'
> debug2: key_type_from_name: unknown key type 'Proc-Type:'
> debug2: key_type_from_name: unknown key type 'DEK-Info:'
> debug2: key_type_from_name: unknown key type '-----END'
> debug1: identity file /Users/gcooper/.ssh/id_rsa type 1
> debug1: identity file /Users/gcooper/.ssh/id_dsa type -1
> debug1: Remote protocol version 2.0, remote software version  
> OpenSSH_4.3
> debug1: match: OpenSSH_4.3 pat OpenSSH*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_4.2
> debug2: fd 3 setting O_NONBLOCK
> debug1: Miscellaneous failure
> No credentials cache found
>
> debug1: Miscellaneous failure
> No credentials cache found
>
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug2: kex_parse_kexinit: diffie-hellman-group-exchange- 
> sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
> debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- 
> cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael- 
> cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
> debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- 
> cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael- 
> cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- 
> ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- 
> ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
> debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
> debug2: kex_parse_kexinit:
> debug2: kex_parse_kexinit:
> debug2: kex_parse_kexinit: first_kex_follows 0
> debug2: kex_parse_kexinit: reserved 0
> debug2: kex_parse_kexinit: diffie-hellman-group-exchange- 
> sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
> debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- 
> cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael- 
> cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
> debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- 
> cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael- 
> cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- 
> ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- 
> ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit: none,zlib@openssh.com
> debug2: kex_parse_kexinit: none,zlib@openssh.com
> debug2: kex_parse_kexinit:
> debug2: kex_parse_kexinit:
> 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-cbc hmac-md5 none
> debug2: mac_init: found hmac-md5
> debug1: kex: client->server aes128-cbc hmac-md5 none
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> debug2: dh_gen_key: priv key bits set: 125/256
> debug2: bits set: 512/1024
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug1: Host 'tebo.cs.washington.edu' is known and matches the RSA  
> host key.
> debug1: Found key in /Users/gcooper/.ssh/known_hosts:43
> debug2: bits set: 504/1024
> debug1: ssh_rsa_verify: signature correct
> debug2: kex_derive_keys
> debug2: set_newkeys: mode 1
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug2: set_newkeys: mode 0
> debug1: SSH2_MSG_NEWKEYS received
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug2: service_accept: ssh-userauth
>
> The only thing I can tell that's different is that I'm trying to  
> connect to a Linux host with an RSA host key, where you're trying  
> to connect to a FreeBSD host with a DSA key. Have you tried  
> deleting or renaming your DSA/RSA public key and then try  
> connecting to the FreeBSD host again?
> -Garrett

	Could you please post your sshd_config?
	Also, from man sshd_config:

      UseDNS  Specifies whether sshd should lookup the remote host  
name and
              check that the resolved host name for the remote IP  
address maps
              back to the very same IP address.  The default is ``yes''.

	So this is just an additional layer to see whether middleman attacks  
are occurring while authenticating, perhaps? UseDNS yes proved to not  
work for me, but it should for you if you have DNS setup properly.
-Garrett



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0B046E68-80D8-4A75-9D4F-354122F7B75F>