100

When I try to ssh, the password prompt takes too long (almost two minutes) to appear.

Why does this happen?

Oxwivi
  • 17,849
Neuquino
  • 1,469

9 Answers9

152

There are several things that can go wrong. Add -vvv to make ssh print a detailed trace of what it's doing, and see where it's pausing.

The problem could be on the client or on the server.

A common problem on the server is if you're connecting from a client for which reverse DNS lookups time out. (A “reverse DNS lookup” means getting back from the client machine's IP address to a host name. It isn't really useful for security, only slightly helpful to diagnose breakin attempts from log entries, but the default configuration does it anyway.) To turn off reverse DNS lookups, add UseDNS no to /etc/ssh/sshd_config (you need to be root on the server; remember to restart the SSH service afterwards).

Another thing that can go wrong is GSSAPI authentication timing out. If you don't know what that is, you're probably not relying on it; you can turn it off by adding the line GSSAPIAuthentication no to /etc/ssh/ssh_config or ~/.ssh/config (that's on the client side).

  • 8
    For me it was the GSSAPIAuthentication problem. Thank you. – RajaRaviVarma Oct 18 '13 at 10:18
  • This has been a problem for me when I ssh into a server in my own apartment. Some combination of DynDNS and port fowarding must've made me hit the DNS timeout issue you described. Thank you! – Jack O'Connor Dec 23 '13 at 10:44
  • I also had to disable GSSAPI, it's enabled by default on Raspberry PI radpbian. – Tomáš Zato Jan 03 '14 at 14:36
  • +1 for GSSAPIAuthentication no ! Vive Gilles ! – Slyx Feb 17 '14 at 15:55
  • 15
    Reverse DNS lookup was my problem – trinth Jun 24 '14 at 19:13
  • 2
    Reverse DNS was the culprit for me as well, and UseDNS no fixed it like a charm. I am on an internal network with no DNS server to handle reverse lookups for internal IPs. – Jordan Mack Dec 16 '14 at 03:53
  • And don't forget to restart the ssh service for this to take effect. – Eden Jan 02 '15 at 09:27
  • Thank you. For me also the GSSAPIAuthentication problem. – Reddi Rajendra P Feb 10 '15 at 04:29
  • The problem arises with Centos 7 new instalation, but both configs resolve the problem, thanks. – Hugo Robayo Oct 07 '16 at 15:15
  • 1
    Are there security implications to disabling GSSAPIAuthentication ? (googling for 15 minutes didn't shed light on that) – Alexander Malakhov Mar 10 '17 at 11:07
  • 3
    @AlexanderMalakhov If you're relying on this to log in, then you'll lock yourself out if you disable it. Other than that, no. And if you're using GSSAPI, you would know — you'd have had to configure some GSSAPI-based service on your network. – Gilles 'SO- stop being evil' Mar 10 '17 at 14:20
  • I tried GSSAPIAuthentication no in /etc/ssh/ssh_config on the client machine and it brought down ssh time from 24 seconds to 1. I did not change anything to ~/.ssh/config as there is no such file on my machine. – smishra Jun 19 '17 at 17:59
  • FWIW, there was no UseDNS yes in my config, so I assumed it was not on by default. (Note: defaults are normally still there in the config, but commented out, for doc. purposes.) Nevertheless, it still was on, and turning it off fixed the delay for me, too. Also note that -vvv doesn't really help in this case, as the debug dump itself also just gets stuck in the middle of a packet exchange, with no clear indication why. (It does suggest it's a server problem, but we already suspected that anyway.) – Sz. Jan 21 '18 at 18:11
  • UseDNS no solved my problem, but it bugs me that not all my Ubuntu servers have this problem which is weird. Some digging into man page shows that some versions of openssh-server on Ubuntu have this option defaults to "yes" while other version have it defaults to "no", that's why only some servers have this problem. – cyfdecyf Mar 15 '18 at 08:18
  • I tested with "UseDNS no", then I checked the /etc/resolv.conf and noticed there were non-responding,, non reachable DNS IP addresses from a previous configuration. I removed them, then the authentication was normal again even with "UseDNS yes" setting. – Gabor Nov 08 '23 at 15:45
16

Let time the login process and see how long it will take:

[root@gislab00207 ~]# time ssh root@ISSLABNTL01
root@isslabntl01's password:
Last login: Fri Oct  4 07:55:03 2013 from 3.60.40.232

[root@ISSLABNTL01 ~]# exit
logout
Connection to ISSLABNTL01 closed.

real    0m45.192s
user    0m0.003s
sys     0m0.005s

You have new mail in /var/spool/mail/root
[root@gislab00207 ~]#

See above it took about 45 seconds to login -------- VERY SLOW

Once You login as root edit sshd_config file and change the UseDNS entry as below. Here I am using sed instead of editing the file.

[root@ISSLABNTL01 ~]# grep -i dns /etc/ssh/sshd_config
#UseDNS yes

[root@ISSLABNTL01 ~]# sed -i 's/#UseDNS yes/UseDNS no/g' /etc/ssh/sshd_config
[root@ISSLABNTL01 ~]# grep -i dns /etc/ssh/sshd_config
UseDNS no

[root@ISSLABNTL01 ~]# service sshd restart
Stopping sshd:                                             [  OK  ]
Starting sshd:                                             [  OK  ]
[root@ISSLABNTL01 ~]# exit

Let us time the login process and see now how long it will takes.

[root@gislab00207 ~]# time ssh root@ISSLABNTL01
root@isslabntl01's password:
Last login: Fri Oct  4 07:55:03 2013 from 3.60.40.232

[root@ISSLABNTL01 ~]# exit
logout

Connection to ISSLABNTL01 closed.

real    0m6.192s
user    0m0.003s
sys     0m0.005s

You have new mail in /var/spool/mail/root
[root@gislab00207 ~]#

See it took now 6 seconds, the time for me to type the password.

Eric Carvalho
  • 54,385
4

It is something that comes wrong from Ubuntu's installation.

To fix it you have to change this line in /etc/nsswitch.conf:

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4

And change it for this one:

hosts:          files dns
Neuquino
  • 1,469
4

In my case, the issue can be solved by restarting systemd-logind:

systemctl restart systemd-logind

This is mentioned on Serverfault.

I have to do this regularly though, and I don’t know what the root cause of the problem is.

1

The debug output for ssh in my case just stopped for 30 seconds while it was 'connecting'. The solution turned out to be related to the DNS settings on my local system. A previous network configuration had left behind a bogus DNS server in the /etc/resolv.conf file. Replacing it with a current DNS server fixed the problem.

0

In my case, DNS was resolving over IPv6, for some reason it made ssh slower. I made an IPv4 entry in /etc/hosts on the client machine, and then ssh/scp was fast again.

tanius
  • 6,303
  • 1
  • 39
  • 49
NRJ
  • 385
  • 1
  • 4
  • 11
0

For me was changing system dns to 127.0.0.1, prior to this is was a non-existing host.

nano /etc/resolv.conf

And write the following

domain localdomain
search localdomain
(Removed this line) ===> nameserver 10.0.0.1
(Added this line) ===> nameserver 127.0.0.1
Eric Carvalho
  • 54,385
0

I don't know as much about the poster's environment as I'd like to, but for others with a similar problem, it may be an issue with sssd, which we use to tie-in ldap mojo.

This happens to me:

$ time ssh server.example.com

real  2m0.018s
user  0m0.006s
sys   0m0.004s

I have to gain access to the server (in my case via the console) then do a:

service restart sssd

After that, things just work. I haven't had time to debug the root cause, but this bandaid works for me.

KurtB
  • 101
0

I could solve the slow password prompt via ssh - issue by checking Enable DNS Relay in DHCP settings on my dlink router. Afterwards connections with SSH worked within a second.

Network Settings -> Router Settings -> Enable DNS Relay [x]

The default configuration forwards every DNS request to the provider. It was slow although I was connecting with ssh pi@10.0.0.103. A hint to the solution was an entry in /etc/resolv.conf "search upc.at" which is provided via dhcp.

The dlink manual states:

When DNS Relay is enabled, DHCP clients of the router will be assigned 
the router's LAN IP address as their DNS server. All DNS requests that 
the router receives will be forwarded to your ISPs DNS servers. 
When DNS relay is disabled, all DHCP clients of the router will 
be assigned the ISP's DNS server.

After a dhcp release on client and server, connecting via SSH was fast again. HTH.

domih
  • 265