always took forever to initiate an SSH connection

[usfish]

Hi all,

The server is using fedora 15. from my computer it always takes forever to initiate a connection. Below is the log. Here MYHOST is not actually an IP address not a hostname, but somehow I kept having this error:

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

How should I resolve it? thanks!

USERNAME@USERNAME-laptop:~$ ssh -v MYHOST
OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to MYHOST [MYHOST] port 22.
debug1: Connection established.
debug1: identity file /home/USERNAME/.ssh/identity type -1
debug1: identity file /home/USERNAME/.ssh/id_rsa type -1
debug1: identity file /home/USERNAME/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.6
debug1: match: OpenSSH_5.6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu4
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied


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: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'MYHOST' is known and matches the RSA host key.
debug1: Found key in /home/USERNAME/.ssh/known_hosts:21
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied


debug1: Next authentication method: publickey
debug1: Trying private key: /home/USERNAME/.ssh/identity
debug1: Trying private key: /home/USERNAME/.ssh/id_rsa
debug1: Trying private key: /home/USERNAME/.ssh/id_dsa
debug1: Next authentication method: password
USERNAME@MYHOST's password:

[marko]

SSH's verbose mode is showing you the problem when it says

debug1: An invalid name was supplied

you did this:

ssh -v MYHOST

But the syntax that ssh wants is either:

ssh -v username@MYHOST

or

ssh -v -l username MYHOST

Here's the entire set of commands that ssh uses with the -l and the other
user@host options bolded

ssh --help

usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-e escape_char] [-F configfile]
[-i identity_file] [-L [bind_address:]port:host:hostport]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-R [bind_address:]port:host:hostport] [-S ctl_path]
[-w local_tun[:remote_tun]] [user@]hostname [command]

[usfish]

Originally Posted by marko

SSH's verbose mode is showing you the problem when it says
you did this:

ssh -v MYHOST

But the syntax that ssh wants is either:

ssh -v username@MYHOST

or

ssh -v -l username MYHOST

Here's the entire set of commands that ssh uses with the -l and the other
user@host options bolded

ssh --help

oh, my local username and the remote username happen to be the same, so i thought ssh MYHOST and ssh USERNAME@MYHOST should be the same?

[stevea]

Originally Posted by marko

SSH's verbose mode is showing you the problem when it says
you did this:

Yes - that's the message of concern ....

ssh -v MYHOST

But the syntax that ssh wants is either:

ssh -v username@MYHOST

or

ssh -v -l username MYHOST

Nope - wrong. The "-l login_name" is optional and the user part of "[user@]host" is optional. That is NOT the problem. The man pages shows thatthe CURRENT local user name is used if none is supplied.

==============

The OP should re-run the ssh command as ...
ssh -vvv MYHOST
and he should also carefully note WHERE i nthe strea mof verbose messages any bit time delay occurs.


I strongly suspect the problem is that his system(s) are trying several authentication methods that are not supported on his systems.

These messages:

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

refer the the Kerberos REALM. Unless this OP want to use Kereros authentication this is a waste of time.

These messages

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic

indicate that gssapi (sort of a secure RPC based on Kerberos) is being tried.


So for most home users the ONLY sorts of ssh authentication they will ever want is password and public-key. If this is the case ,then the solution is to change the ssh or sshd configuration.

If the OP controls the server (the Ubuntu sshd server) then he can modify the /etc/ssh/sshd_config file.
Adding these lines to the TOP of that file and restarting the server will limit the accepted authentication methods:

ChallengeResponseAuthentication no
GSSAPIAuthentication no
KerberosAuthentication no
PasswordAuthentication yes
PubkeyAuthentication yes
RSAAuthentication no
RhostsRSAAuthentication no

Then reboot server or restart the sshd service.


You can also control the Auth order this from the client. On the client you can edit the /etc/ssh/ssh_config file and change the contents to contain this line.

PreferredAuthentications publickey,keyboard-interactive,password,gssapi-with-mic,hostbased

[smr54]

It's also useful to stop sshd and run it with -ddd (for debug) on the remote host.

Often, a delay is caused by the remote machine trying to do remote DNS lookup. This can sometimes be fixed by having the client and host in each other's /etc/hosts files.

One way to test is to briefly, on the server, look for the line

#UseDNS yes

Uncomment it, change it to no so that it looks like

UseDNS no

if the connection is then quick, that's the answer, and usually, adding the server and client to each other's host files will fix it.

[stevea]

Good ideas - tho I think
sshd -Dddd
which keeps sshd in foreground might be a notch better.

You may be right about DNS - but probably it's trying to resolve kerberos realms - which is dependent on the DNS.
Getitng rid of unneeded authentications is likely to solve the problem.

[smr54]

Thank you stevea, that's actually what I meant to write--shouldn't post so late. Yes, stop sshd in /etc/services (service sshd stop) and start it in the foreground, the way stevea has posted in bold. Although, in practice, I've never had to put the -D (the upper case D means run in foreground) to get it to run in the foreground, it's better to use the correct command than to do it sloppily and hope it might work.

[DHR]

I had this problem. It is probably true that I could have avoided it by suppressing GSSAPIAuthentication. But since I've never had to do that before, I tried to figure out a different solution.

It turns out that the server's IP address had no reverse DNS entry. When I fixed that, the login speed was much better. Of course not everyone has the authority to fix reverse DNS entries for the IP address that they care about.