2

I have an Ubuntu 9.04 server. I am facing a long delay while doing SSH to the server. I have added "UseDNS no" in sshd_conf and commented out "GSSAPIAuthentication yes" in ssh_conf, still the problem is there.

On seeing /etc/resolve.conf, it looks like the problem is there.

Contents of /etc/resolve.conf:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 10.xx.xx.xx nameserver 10.xx.xxx.xx search xyz.com

I read somewhere that multiple nameserver entries here can cause problems. I am using a VPN client on that server to connect to my company's network, and it looks like the entries are automatically added by the vpn client.

How do I fix these long delays without breaking my VPN client/connections. I don't mind not being able to use my companies server names/aliases while connection via VPN from my server, but would like to fix the long SSH delay while connecting to the server.

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

  1. Yes, I meant /etc/sshd_conf

  2. I am using IP address to connect directly

  3. I am not using VPN to connect to my server (where there is delay). However, a VPN client is running on the server to further connect to some other network. The login FROM my server using the VPN client is fast enough.

  4. Sorry, I didnt understand AddressFamily, inet, and some other comments.

Here are debug logs on client side (with approx. delays):

OpenSSH_5.6p1, OpenSSL 0.9.8o 01 Jun 2010 debug1: Connecting to ...... debug1: Connection established. debug1: identity file ..... type -1 debug1: identity file ..... type -1 debug1: identity file ..... type -1 debug1: identity file ..... type -1

NOW THERE IS 4 SECONDS PAUSE 

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5ubuntu1 debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.6 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

NOW THERE IS 15-20 SECONDS PAUSE

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

NOW THERE IS 40-50 seconds PAUSE

Then it checks fingerprint etc and connects fast.

Improve this question
2
  • 2
    You edited your answer to say that you really did edit /etc/sshd_conf. That's fine, but I believe Ubuntu ignores that file. Ubuntu has that file stored in /etc/ssh/ssd_config, and won't use the other file unless you've done something very strange to your system. Commented Oct 15, 2010 at 20:01
  • Did /etc/resolv.conf actually point to valid DNS servers? I have a slow ssh login because /etc/resolv.conf points to an invalid DNS server. Commented Jun 27, 2023 at 4:06

6 Answers 6

Reset to default
5

sshd_conf

Just to be sure, you really mean /etc/ssh/sshd_config, not sshd_conf, right? I don't think that sshd_conf or sshd.conf are valid files for OpenSSH on Ubuntu, so editing them will do nothing.

I read somewhere that multiple nameserver entries here can cause problems.

Multiple nameservers in /etc/resolv.conf should not cause any problems, although if the first nameserver on the list is slow, it will affect your system. In fact it's a good practice to list redundant nameservers in /etc/resolv.conf in case one nameserver goes down.

Before you dig too deep, try to determine if this problem is on the client side or the server side.

On the client side, turn on SSH verbose mode. This will tell you the progress of the client connection to the server. If the connection from the client to the server is slow, you might see a delay before lines like "debug1: Connection established." or "debug1: Server accepts key: pkalg ssh-dss blen 435".

On the server side, tail the SSH logs in a separate window and watch the logs. You might want to increase the logging to "VERBOSE".

Update:

Don't use sshd_conf. Add the following to /etc/ssh/sshd_config , restart SSH and then let us know what happens.

UseDNS no

Change one thing at a time. If UseDNS doesn't work, then try "GSSAPIAuthentication no".

Improve this answer
1
  • UseDNS no on my bastion host increased connection speed from 10 second avg wait, to < 1sec. thank you! Commented Dec 7, 2016 at 9:07
1

You should be able to create your own user level config file in ~/.ssh/config

From here you can map the host to the numeric ip and it should bypass the DNS lookup altogether. For example say you want to ssh to "glitch.somewhere.net", in your config file do something like:

Host glitch HostName 192.168.0.1 User JP19

You can insert a ton of options here as describe in the ssh_config man page (man ssh_config). The key here is that the "HostName" is actually set to a numeric IP rather than a true hostname. Essentially you're setting up multiple shortcuts. So you can ssh to glitch1, glitch2, goog, ...

One potential gotcha, is to make sure the permissions are set correctly so that ssh doesn't freak out. Also, I'd recommend running ssh in verbose mode (ssh -vvv) to make sure it is hanging where you think it is, but I suspect you're on the right trail.

Improve this answer
0

First questions, are you connecting via IP Addresses to the servers or via Domain names?

Second question, are you able to connect to the servers externally or only through the VPN?

The likely cause of the delay is the VPN and connection speeds, not necessarily the result of an SSH connection.

Improve this answer
0

Could you try AddressFamily inet ? It disables ipv6 which triggers a bug in some old systems (it's in the openssh faq).

Perhaps a bit silly but did you restart the ssh server after making the changes?

Improve this answer
0

Problem

I had similar problem logging into CentOS/Fedora servers from my Fedora laptop. When connecting from an external network, the process was quick, with a two, maybe three, second delay before the password prompt came up. However, connecting from the internal network, it would take 10-20 seconds to get to the password prompt.

Solution:

edit ~/.ssh/config

Host 192.168.0... (your target ip) GSSAPIAuthentication no PasswordAuthentication yes ChallengeResponseAuthentication no ForwardX11 yes

Make sure that ~/.ssh/config permissions are read-only for group/others, write only for user. (chmod to 644).

Improve this answer
0

A log delay while using SSH could be also caused by blocked processes and/or cron-jobs misconfiguration, so check them also (i.e. crontab -l)

Improve this answer

You must log in to answer this question.