Hello ALUG,
I've noticed recently that all my SSH logins take some time (around 5-10 seconds). I found that I can configure sshd with the option:
UseDNS no
to fix this. However, that's not quite satisfactory. For one thing, I can only do that on hosts where I manage the sshd. And for another, it doesn't explain why connecting to *all* the servers I normally do became slow at the same time. So I've been looking for anything on my local computer that's making them slow but so far haven't been able to find anything.
From the verbose output I can see that ssh waits after:
debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/mas01rl/.ssh/id_rsa (0x7fc503a76690), debug2: key: /home/mas01rl/.ssh/id_dsa ((nil)), debug2: key: /home/mas01rl/.ssh/id_ecdsa ((nil)), debug2: key: /home/mas01rl/.ssh/id_ed25519 ((nil)),
and then continues from:
debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive,password
after a pause of 5-10 seconds.
I noticed some discussion about the GSSAPI key exchange and how that can cause delays if you don't have Kerberos credentials. So I tried disabling it, but that didn't make any difference; and there weren't any relevant Kerberos error messages in the output anyway. (Also notice from the above output that I also tried changing the order of authentication methods to make GSSAPI come after publickey.)
Any suggestions what else could be wrong? Or is it really that all the servers need to have 'UseDNS no'? And if so, what has changed about them all to make this necessary? Or could it be something to do with my network set up?
Thanks, Richard
On Thursday 15 Jan 2015 10:06:43 Richard Lewis wrote:
Hello ALUG,
I've noticed recently that all my SSH logins take some time (around 5-10 seconds). I found that I can configure sshd with the option:
UseDNS no
to fix this. However, that's not quite satisfactory. For one thing, I can only do that on hosts where I manage the sshd. And for another, it doesn't explain why connecting to *all* the servers I normally do became slow at the same time. So I've been looking for anything on my local computer that's making them slow but so far haven't been able to find anything.
From the verbose output I can see that ssh waits after:
debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/mas01rl/.ssh/id_rsa (0x7fc503a76690), debug2: key: /home/mas01rl/.ssh/id_dsa ((nil)), debug2: key: /home/mas01rl/.ssh/id_ecdsa ((nil)), debug2: key: /home/mas01rl/.ssh/id_ed25519 ((nil)),
and then continues from:
debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive,password
after a pause of 5-10 seconds.
I noticed some discussion about the GSSAPI key exchange and how that can cause delays if you don't have Kerberos credentials. So I tried disabling it, but that didn't make any difference; and there weren't any relevant Kerberos error messages in the output anyway. (Also notice from the above output that I also tried changing the order of authentication methods to make GSSAPI come after publickey.)
Any suggestions what else could be wrong? Or is it really that all the servers need to have 'UseDNS no'? And if so, what has changed about them all to make this necessary? Or could it be something to do with my network set up?
Thanks, Richard
I had a similar problem once - I fixed it by adding an entry in /etc/hosts for it's IP address
On 15 Jan 10:06, Richard Lewis wrote:
Any suggestions what else could be wrong? Or is it really that all the servers need to have 'UseDNS no'? And if so, what has changed about them all to make this necessary? Or could it be something to do with my network set up?
If UseDNS no fixes it it suggests that you've got broken reverse DNS.
Out of interest, are the hosts that you're trying to connect to over IPv4 or IPv6? And have you got working reverse DNS on the IP that you're connecting from? The ssh daemon by default does a reverse lookup on the IP, and so will stall if there isn't one for a bit.
Thanks,
On Thu, 15 Jan 2015 13:09:08 +0000 Brett Parker iDunno@sommitrealweird.co.uk allegedly wrote:
On 15 Jan 10:06, Richard Lewis wrote:
Any suggestions what else could be wrong? Or is it really that all the servers need to have 'UseDNS no'? And if so, what has changed about them all to make this necessary? Or could it be something to do with my network set up?
If UseDNS no fixes it it suggests that you've got broken reverse DNS.
Out of interest, are the hosts that you're trying to connect to over IPv4 or IPv6? And have you got working reverse DNS on the IP that you're connecting from? The ssh daemon by default does a reverse lookup on the IP, and so will stall if there isn't one for a bit.
Thanks,
And a good test for that is to add the IP address of the client to the hosts file of the server and ensure that the order of DNS resolution (/etc/nsswitch.conf) is files first, then DNS.
Mick
---------------------------------------------------------------------
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net
---------------------------------------------------------------------
At Thu, 15 Jan 2015 13:29:15 +0000, mick wrote:
On Thu, 15 Jan 2015 13:09:08 +0000 Brett Parker iDunno@sommitrealweird.co.uk allegedly wrote:
On 15 Jan 10:06, Richard Lewis wrote:
Any suggestions what else could be wrong? Or is it really that all the servers need to have 'UseDNS no'? And if so, what has changed about them all to make this necessary? Or could it be something to do with my network set up?
If UseDNS no fixes it it suggests that you've got broken reverse DNS.
Out of interest, are the hosts that you're trying to connect to over IPv4 or IPv6? And have you got working reverse DNS on the IP that you're connecting from? The ssh daemon by default does a reverse lookup on the IP, and so will stall if there isn't one for a bit.
Thanks,
And a good test for that is to add the IP address of the client to the hosts file of the server and ensure that the order of DNS resolution (/etc/nsswitch.conf) is files first, then DNS.
Thanks, both. It seems this is a reverse DNS problem. I'm making my SSH connections from a host on the gold.ac.uk network, but trying reverse DNS lookup of the IP address of that host results in SERVFAIL after a 5-10 second delay. I asked our departmental system administrator about it and he's escalated to the College IT services. I also checked that connecting from a host outside the College network does not result in a delay.
Richard