Debug1: Host '62.182.56.139' is known and matches the ECDSA host key. I am using ubuntu 13.10, and the server runs ubuntu 12.04. I had generate private and public keys using ssh-keygen, and put idrsa.pub to server side and added it to authorziedkeys accordding to the. By default, ssh searches for iddsa and idrsa files. The keys do not have to be named like this, you can name it mykey just as well, or even place it in a different directory. However, if you do either of those, then you need to explicitly reference the key in the ssh command like so.

1. debug1: identity file /root/.ssh/id_rsa type 1
2. debug1: identity file /root/.ssh/id_rsa-cert type -1
3. debug1: identity file /root/.ssh/id_dsa-cert type -1
4. debug1: identity file /root/.ssh/id_ecdsa type -1
5. debug1: identity file /root/.ssh/id_ecdsa-cert type -1
6. debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1-hpn13v11
7. debug1: match: OpenSSH_5.9p1-hpn13v11 pat OpenSSH*
8. debug1: Enabling compatibility mode for protocol 2.0
9. debug1: Local version string SSH-2.0-OpenSSH_5.9p1-hpn13v11
10. debug1: SSH2_MSG_KEXINIT received
11. debug1: REQUESTED ENC.NAME is 'aes128-ctr'
12. debug1: kex: server->client aes128-ctr hmac-md5 none
13. debug1: kex: client->server aes128-ctr hmac-md5 none
14. debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
15. debug1: Server host key: ECDSA d9:8b:2e:2a:2c:b0:07:c0:47:47:6e:8a:4e:e8:ff:13
16. debug1: Host '62.182.56.139' is known and matches the ECDSA host key.
17. debug1: ssh_ecdsa_verify: signature correct
18. debug1: expecting SSH2_MSG_NEWKEYS
19. debug1: Roaming not allowed by server
20. debug1: SSH2_MSG_SERVICE_ACCEPT received
21. debug1: Authentications that can continue: publickey,keyboard-interactive
22. debug1: Offering RSA public key: /root/.ssh/id_rsa
23. debug1: Authentications that can continue: publickey,keyboard-interactive
24. debug1: Trying private key: /root/.ssh/id_ecdsa
25. debug1: Next authentication method: keyboard-interactive

On fresh installed Linux servers you might have encountered that it takes quite some time before you get to see the password prompt when you connect using SSH. As soon as you entered the password everything is lightning fast. There are two items that might cause this problem:

• DNS Resolving
• Authentication methods that are not supported.

DNS Resolving

The DNS problem is easy to fix, make sure the SSH server is able to resolve DNS queries by configuring a DNS server. Here’s how to do it on a CentOS server:

And add the following lines:

I’m using the DNS servers from OpenDNS, use any server you like. This will allow your server to perform DNS lookups. You can also tell SSH to disable DNS lookups like this:

And change the “UseDNS yes” field to “UseDNS no”.

This will ensure that SSH doesn’t try to do any reverse lookups. Don’t forget to restart SSH! If your SSH connection time is still slow after these changes, read on…

Authentication

SSH supports a number of authentication methods besides username/password. Let me show you what is happening behind the scenes when you are waiting for the password prompt:

I’m going to connect to a SSH server but I’ll use the “v” parameter (verbose). Here’s what you will see:

Before it shows you the password prompt, SSH will first try to connect using GSSAPI-KEYEX, GSSAPI-WITH-MIC and Public Key. Since I’m not using these it’s causing a delay when trying to connect to SSH. Especially the GSSAPI-WITH-MIC is taking a long time…let’s disable it:

Now change the “GSSAPIAuthentication yes” line to “GSSAPIAuthentication no”.

Restart SSH and try to connect again:

With GSSAPI disabled it’s flying!

Debug1 No Xauth Program

Debug1: No More Authentication Methods To Try

I hope this lesson helps you to solve your SSH login delay…if you have any questions feel free to leave a comment.