Long delays on SSH login from an Ubuntu system

Bug #111553 reported by Dmitriy Kropivnitskiy
14
Affects Status Importance Assigned to Milestone
openssh (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

Binary package hint: openssh-client

When trying to SSH from a freshly installed and updated Feisty system, there is a delay of several seconds (like 5-10) before the login goes through. After the login goes through all the rest of the operation is normal. I have tried to login into different systems including RHEL4, CentOS 4 and FreeBSD with the same result. Using -vvv switch to SSH I have found the following: (pasting only relevant part of the log):

debug1: identity file /home/jeld/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1
debug2: fd 3 setting O_NONBLOCK
debug1: Miscellaneous failure
Improper format of Kerberos configuration file

debug1: Miscellaneous failure
Improper format of Kerberos configuration file

debug1: Miscellaneous failure
Improper format of Kerberos configuration file

debug1: Miscellaneous failure
Improper format of Kerberos configuration file

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

I have installed krb5-config and the problem went away. I suppose the solution would be to either include krb5-config with the main install, so there is a minimal config file, or recompile SSH without kerberos support.

Revision history for this message
Adam Cankudis (acan) wrote :

I can confirm this. After upgrade from Ubuntu 6.06 to 7.04 I noticed some delays between invoking ssh (in the shell) and password prompt.
I do some search with Wiershark, and I could see that client key exchange init time delta from previous packet is over 10 sec., i.e:
pkt 10: SSH v2 Server: Key Exchange Init, Time delta from previous packet = 0.015022000 s.
pkt 11: Client to Server ACK, Time delta from previous packet = 0.039764000 s.
pkt 12: SSH v2 Client: Key Exchange Init, Time delta from previous packet = 10.89677000 s.
I've installed krb5-config as Dimitriy suggest, and client key exchange init time delta is reduced to 0.040810000 s. or less.

I think it is not a good idea to recomplie openssh-client without kerberos support. The better way, IMHO, is to include krb5-config package as dependency for openssh-client pkg.

Revision history for this message
Steff Davies (steff) wrote :

I can confirm this - I had this problem on an Edgy machine upgraded to Feisty (this machine at which I sit, in fact) as did my PFY on his box.

After a swift google, I found some blog entries which suggested unticking the "Automatic service discovery" box in the "General" tab of Network Settings. This fixed it for me and the PFY. NB I have no idea what else this may break, but since the vast bulk of my work is over ssh it came as a great relief.

Revision history for this message
stormreaver (kubuntu-tonyobryan) wrote :

I can confirm this also. I can also confirm that installing krb5-config on Feisty 7.04 removes the excessive delay. When I upgraded from Fedora Core 6 to Kubuntu Edgy, I started having the 10-15 second delays (a problem I never got around to addressing until today). I installed krb5-config, and the delay became almost unnoticeable.

Revision history for this message
André Klitzing (misery) wrote :
Revision history for this message
Tom Green (tom-slaxicon) wrote :

I can also confirm this. The delay was unbearable till I installed krb5-config as mentioned above. Now it is fine. Feisty on a Dell E1705 laptop.

Revision history for this message
Siegfried Gevatter (rainct) wrote :

I can also confirm this. It needs over 20 seconds until it asks me for the key password, but once I logged in once then it goes fast (until I restart the PC).

Changed in openssh:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
JoeBrouhard (jbrouhard) wrote :

Just so i can understand this bug, are you guys logging INTo a fiesty machine, or logging from a fiesty machine to another server?

Cause I just tried to log in via SSH to my work server from my laptop, which has fiesty installed. However, it went through relatively fast, with no delay?

I need a little more clarification before I can comment more either way. Thanks in advance!

Revision history for this message
Dmitriy Kropivnitskiy (nigde) wrote :

Read the original bug report. It clearly states that we are talking about logging FROM a Feisty system into a generic (different distro's or even OSs) server. Seems like default SSH client config is trying to use kerberos and kerberos is not configured in any way by default

Revision history for this message
Siegfried Gevatter (rainct) wrote :

I'm logging from a Feisty into a Feisty machine, both in the same local network. However, doing some thinks I found here in Launchpad and in Ubuntu Forums I got it to working great, taking just 1 second to log in. What I did is:

 - On /etc/ssh/ssh_config, uncomment "ForwardX11 no" (I can see GUI's anyways - passing the -X option).

 - On /etc/ssh/ssh_config, change "GSSAPIAuthentication" to "no".

 - On /etc/ssh/ssh_config, add "AddressFamily inet" (or call ssh with the -4 option).

 - Install krb5-config.

 - Change some other configuration file. I can't remember which nor what I put there, but I think it was something about DNS.

 - Do *not* disable "Search for services [...]" (in System -> Administration -> Network -> General) as disabling it made it slower.

Revision history for this message
Dmitriy Kropivnitskiy (nigde) wrote :

It seems that GSSAPIAuthentication is the important one, since it is the authentication method that uses kerberos

Revision history for this message
Nicolas Valcarcel (nvalcarcel) wrote :

This bug is a duplicate of https://bugs.edge.launchpad.net/ubuntu/+source/openssh/+bug/84899 marked as invalid

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.