3

SSH connecting with key, from my machine suddenly got incredibly slow (~10sec!). It is not a server or DNS problem as far as I can figure out.

The problem suddenly appeared after a simple apt-get install kubuntu-desktop and some minor KDE related mucking around, on my Ubuntu 15.04 x86_64.

Running ssh -vv ... shows me that it waits for ages (most of the ~10sec...) at the last line from this:

OpenSSH_6.7p1 Ubuntu-5ubuntu1, OpenSSL 1.0.1f 6 Jan 2014 debug1: Reading configuration data /home/neuronq/.ssh/config debug1: /home/neuronq/.ssh/config line 1: Applying options for XXX.com debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for *

...and my /etc/ssh/ssh_config contains this (I didn't paste the commented out lines):

Host *
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication no
    GSSAPIDelegateCredentials no

Is there any way in which Kubuntu desktop install can suddenly result in this slowdown (some keystore/wallet weird thing)? (Also, in KDE I couldn't get ssh login by key to work at all, except in the terminal by manually doing a ssh-add beforehand and entering my key passphrase, but I've since given up on KDE completely and I'm back to Unity, so I don't longer care about this... but it could be related)

NeuronQ
  • 131
  • 1
  • 5
  • 2
    What does `/etc/ssh/sshd_config` on the server side look like? It may help to have `UseDNS no` in that configuration file. – kasperd May 16 '15 at 10:00
  • @kasperd the sshd_config on the server side is surely not the issue, as it has not been changes since before my slowdown, when things were working fast enough, and also all the other people connecting to it don't have this problem – NeuronQ May 17 '15 at 07:45
  • @kasperd thanks for the answer, but the solution to my problem was simply adding a `AddressFamily inet` on my side. I answered myself in case anyone else has the same problem. – NeuronQ May 17 '15 at 08:57
  • 1
    @NeuronQ Even though the issue may have been caused by something other than your server, knowing its configuration may still be of use in pin-pointing the problem. – Jenny D May 17 '15 at 09:53
  • 1
    @NeuronQ Having sshd perform DNS lookups introduce a needless dependency. Each dependency is one more thing that can cause your setup to stop working without you having changed anything on your own. Your sshd depends on DNS lookups and the DNS server it uses breaks, then it is a server side problem, even if you didn't change anything. – kasperd May 17 '15 at 10:15
  • I just experienced this problem and rebooting the server solved the problem. It must have been some service that needed to be restarted after a package upgrade. – August Karlstrom Feb 11 '16 at 16:00

2 Answers2

4

Do you have the same troubles by password authentication, or this is really related to key authentication?

You client may provide proper DNS resolution, but it is your server which will try anyway to perform a reverse-lookup from your IP address; this may explain the delay, as @kasperd says. But from experience, this does not exceed a few seconds.

Does SSH succeeds in authentication finally? If so, it really looks like a DNS problem. Try if your configuration/administrator permits so adding your IP/hostname into the server's /etc/hosts. This will bypass the DNS resolution on server side. If you won't configure your DNS to provide proper reverse-lookup on server side for the client, useDNS no is, as @kasperd says, to be put on the /etc/ssh/sshd_config of the server.

If your administrator won't do this, there is nothing more your can do.

EDIT: There is absolutely no way KDE/Unity or any desktop manager could result in this slowdown. I would be amazingly surprised this is the case. However, the fact you need to provide ssh-add to use your keys is interesting. This command is used to make your authentication agent to remember the passphrases you tipped for your keys. To specify key to be used, either do it by command line, or in your ~/.ssh/config file:

# in your command line:
ssh -i /path/to/your/private/key user@host

# or in your /home/$user/.ssh/config file:
# (on command line later, simply use ssh user@host or ssh host if
# user locally and remotely are the same
Host $myhost
    IdentityFile /path/to/your/private/key
    IdentitiesOnly yes
philippe
  • 2,131
  • 4
  • 30
  • 53
  • The server's config is definitely not the problem. It hasn't been changed since before I started experiencing the slowdown. Also, everyone else connecting to it the same way does not experience the slowdown I experience. **I'm 100% sure it's something on my machine.** And I think it has something to do with kubuntu-desktop because after installing it and trying to get dolphin to do key based login, **the gnome/unity terminal suddenly stopped asking me for my ky passphrase after every boot, as it did before**... – NeuronQ May 17 '15 at 07:51
  • ...the kubuntu problem I was referring to was somehow related to this https://bugs.launchpad.net/ubuntu/+source/kde-runtime/+bug/1450085 and http://askubuntu.com/questions/598455/problems-with-kio-sftp-in-dolphin-konqueror but I've totally given up on solving it because it was a maddedingly complicated scenario with gnome-keyring fighting with kio and with kwallet on top of the ecdsa with libssl vs openssh etc. ...it was just an insanely deep rabbit hole I jsut don't wanna go into ever again – NeuronQ May 17 '15 at 07:57
  • Also, yes, the problem is the same with password authentication. And the login works in the end after a ~10sec delay. – NeuronQ May 17 '15 at 07:59
  • Thanks a lot for taking time to answer. But for me the solutions turned up to be a simple `AddressFamily inet` added to the config. And the problem was probably triggered by some package upgrade, not by kde-desktop, you're right. – NeuronQ May 17 '15 at 08:56
0

For me the actual solution was adding AddressFamily inet on my localhost to either ~/.ssh/config for the appropriate host or /etc/ssh/ssh_config for Host *.

The cause of the problem was most likely the recent upgrade to Ubuntu 15.05 and ssh was now trying (but failing, with a huge delay...) to use IPv6.

NeuronQ
  • 131
  • 1
  • 5
  • Ah, OK, you client was trying to negotiate IPv6 first! haven't though of it. – philippe May 17 '15 at 09:17
  • 1
    That's not solving the problem, that's just hiding it. Sooner than you think, you are going to need to connect to an ssh server over IPv6. At that time you'll have to revert that change, and you still won't have fixed the original problem. Moreover the real problem (which you haven't solved yet), is likely going to break other things for you. The ssh client is not the only software which supports IPv6. Other software with IPv6 support is also going to be affected by your misconfigured network connectivity. – kasperd May 17 '15 at 10:23
  • First thing you need to check is the AAAA record of the server. Is that AAAA record correct? If the AAAA record is incorrect, then that's the real problem which needs fixing. If the AAAA record is correct, then the next thing you need to check is the IPv6 connectivity of the server. If the server has an AAAA record but the IPv6 connectivity of the server is broken, then that's going to cause problems. And in that case you need to fix the IPv6 connectivity of the server. – kasperd May 17 '15 at 10:25
  • If there aren't any problems on the server side, then you have to verify what happens on the client side. Check what route the client uses towards the IPv6 address of the server. Also check what source IP is chosen for that route. If there is no route, then the ssh client is supposed to switch to IPv4 instantly. If there is a route, but the source IP for that route is incorrect, then that's what you need to fix. Finally if neither of those are the source of the problem, then that means IPv6 connectivity between client and server is supposed to work. – kasperd May 17 '15 at 10:28
  • If you have a setup in which IPv6 connectivity between client and server is supposed to work but doesn't, then that's the problem you need to fix. In that case a traceroute from each end towards the other end is likely to reveal the problem. (Here is a nice thing about running dual stack. It gives you some more redundancy which allows you to connect to the server even when one of the protocols is misconfigured. Had you only been running one of the two, it would be much harder to run a traceroute from both ends when it broke.) – kasperd May 17 '15 at 10:31