We have most of our colo servers set up to allow us to ssh into them from our office at a remote location, and we just installed our first Fedora server to operate as a data server because I'm most familiar with Fedora and mysql runs better on linux vs bsd. Anyway, we were able to ssh into it just fine from our office when it was up here being configured, but after moving it down to our colo it will only really complete an ssh connection from another server in our colo. We can't seem to get it to ssh in from our office unless we run sshd in debug mode (which exists after the connection closes). I've done some debugging and tried suggestions I found on google regarding these messages, but nothing has really helped. However, negotiation time from colo-to-colo is now faster, but it doesn't fix our office-to-colo problem.
In debug2 mode, both server and client spew out these messages simultaneously:
Then both client and server just sit there doing what seems to be nothing at all. Then the client says some junk on its own:
And then the server shows a message:
Then they pause for 30 seconds again and then the client spews out this junk:
I've turned off UseDNS and this is still happening even though people suggested doing so. I have a feeling this is all due to something on the client's config because both server and client pause for like 30+ seconds and then the client spews out the "Cannot determine realm for numeric host address" messages and only after that does the server show any more messages before the connection is closed.
Steve Kiehl
Web Page Designer - Nanovox Productions
Unwords Dictionary of Made-Up Words
In debug2 mode, both server and client spew out these messages simultaneously:
Code:
Client:
OpenSSH_3.8.1p1, OpenSSL 0.9.7i 14 Oct 2005
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.0.0.18 [10.0.0.18] port 22.
debug1: Connection established.
debug1: identity file /Users/kiehlster/.ssh/identity type -1
debug1: identity file /Users/kiehlster/.ssh/id_rsa type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /Users/kiehlster/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.0
debug1: match: OpenSSH_4.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1
Code:
Server:
Jan 27 09:22:01 richard sshd[13663]: debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7
Jan 27 09:22:01 richard sshd[13616]: debug1: Forked child 13663.
Jan 27 09:22:01 richard sshd[13663]: debug1: inetd sockets after dupping: 3, 3
Jan 27 09:22:01 richard sshd[13663]: Connection from 192.168.0.35 port 51679
Jan 27 09:22:01 richard sshd[13663]: debug1: Client protocol version 2.0; client software version OpenSSH_3.8.1p1
Jan 27 09:22:01 richard sshd[13663]: debug1: match: OpenSSH_3.8.1p1 pat OpenSSH_3.*
Jan 27 09:22:01 richard sshd[13663]: debug1: Enabling compatibility mode for protocol 2.0
Jan 27 09:22:01 richard sshd[13663]: debug1: Local version string SSH-2.0-OpenSSH_4.0
Jan 27 09:22:01 richard sshd[13663]: debug2: fd 3 setting O_NONBLOCK
Jan 27 09:22:01 richard sshd[13663]: debug2: Network child is on pid 13664Then both client and server just sit there doing what seems to be nothing at all. Then the client says some junk on its own:
Code:
debug1: An invalid name was supplied
Cannot determine realm for numeric host address
debug1: An invalid name was supplied
A parameter was malformed
Validation errorAnd then the server shows a message:
Code:
Jan 27 09:24:01 richard sshd[13663]: debug1: do_cleanup
Jan 27 09:24:01 richard sshd[13663]: debug1: PAM: cleanupThen they pause for 30 seconds again and then the client spews out this junk:
Code:
debug1: An invalid name was supplied
Cannot determine realm for numeric host address
debug1: An invalid name was supplied
A parameter was malformed
Validation error
debug1: SSH2_MSG_KEXINIT sent
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-cbc,3des-cbc,blowfish-cbc,cast128-cbc,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,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
debug2: kex_parse_kexinit: none,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,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,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
debug2: kex_parse_kexinit: none,zlib
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
Connection closed by 10.0.0.18I've turned off UseDNS and this is still happening even though people suggested doing so. I have a feeling this is all due to something on the client's config because both server and client pause for like 30+ seconds and then the client spews out the "Cannot determine realm for numeric host address" messages and only after that does the server show any more messages before the connection is closed.
Steve Kiehl
Web Page Designer - Nanovox Productions
Unwords Dictionary of Made-Up Words
![[thumbsup2]](/data/assets/smilies/thumbsup2.gif "[thumbsup2] [thumbsup2]")