delay when connecting via ssh [SOLVED]

graysky · 2011-10-19 13:18:59

Recently, one of my boxes began pausing for 5-7 sec after I connect via ssh. Any ideas as to a cause?

$ ssh facade@io
Last login: Tue Oct 18 19:38:35 2011 from mars

<<<DELAY>>>

[facade@io ~]$

Last edited by graysky (2011-10-19 18:40:24)

R00KIE · 2011-10-19 13:41:03

Try to set "Use DNS" to no in /etc/ssh/sshd_config (and restart sshd obviously) and see if you still get a delay.

If the answer is yes then check the dns servers you have configured as most probably one of them is not working properly. If the answer is no then I have no other ideas.

graysky · 2011-10-19 13:52:23

@R - no change with "Use DNS No"
Thanks for the suggestion though.

R00KIE · 2011-10-19 14:00:32

It should be UseDNS, no space, my bad. But I guess you saw the option and just changed yes to no and uncommented it.

But if this didn't work then try using ssh -v (or -vv) and post the output and maybe someone will see something that is not right.

graysky · 2011-10-19 14:56:38

Good idea. I did it, but the delay didn't happen until all the debug stuff scrolled paste. Again, it is after the "last connection from" appears. Perhaps this isn't a problem with SSHD but with something else?

$ ssh -vv facade@io
OpenSSH_5.9p1, OpenSSL 1.0.0e 6 Sep 2011
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to io [192.168.1.22] port 22.
debug1: Connection established.
debug1: identity file /home/facade/.ssh/id_rsa type 1
debug1: identity file /home/facade/.ssh/id_rsa-cert type -1
debug1: identity file /home/facade/.ssh/id_dsa type -1
debug1: identity file /home/facade/.ssh/id_dsa-cert type -1
debug1: identity file /home/facade/.ssh/id_ecdsa type -1
debug1: identity file /home/facade/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 31:a2:dd:53:73:1a:e9:81:2a:da:93:96:62:0a:fb:c4
debug1: Host 'io' is known and matches the ECDSA host key.
debug1: Found key in /home/facade/.ssh/known_hosts:16
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/facade/.ssh/id_rsa (0x22459a0)
debug2: key: id_rsa_godaddy (0x2246050)
debug2: key: /home/facade/.ssh/id_dsa ((nil))
debug2: key: /home/facade/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/facade/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug2: input_userauth_pk_ok: fp 51:7b:09:71:f1:c0:26:3b:4c:3c:80:c5:c8:9e:45:35
debug1: Authentication succeeded (publickey).
Authenticated to io ([192.168.1.22]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 3 setting TCP_NODELAY
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Wed Oct 19 10:45:06 2011 from mars

<<<DELAY IS HERE>>>

$

R00KIE · 2011-10-19 15:29:14

Then I can only think of something that is run at the server side after login. Maybe something in /etc/profile.d/ or something in ~/.bashrc or ~/.bash_profile or equivalent if you are using another shell. You could check this if you have access to the server and login in a tty, it should show the same delay between login and showing you the prompt.

You could also try to check what changed around the same time this problem started happening.

graysky · 2011-10-19 17:33:54

Good advice, Rookie. I'll try it and let report back.

graysky · 2011-10-19 18:40:15

You know, I forgot to mention that the delay is only present the first time I connect following a reboot. Subsequent connections are more or less instantaneous. I removed my ~/.bashrc and rebooted. Instantaneous connection. I went through line-by-line and found the offending line to be:

[[ -f /etc/bash_completion ]] && . /etc/bash_completion

I removed it, rebooted and now, no delay. I can't remember why that's in there in the first place since Arch has no such file.

Thanks for you advice!

R00KIE · 2011-10-19 19:14:01

graysky wrote:

I removed it, rebooted and now, no delay. I can't remember why that's in there in the first place since Arch has no such file.

Maybe at some point in time you had bash-completion installed and configured your .bashrc to use it.

Glad I could help

graysky · 2011-10-19 19:20:23

R00KIE wrote:

Maybe at some point in time you had bash-completion installed and configured your .bashrc to use it.
Glad I could help

Could be as that file would have migrated with my $HOME over the distros I left in my wake before discovering Arch.

Arch Linux

#1 2011-10-19 13:18:59

delay when connecting via ssh [SOLVED]

#2 2011-10-19 13:41:03

Re: delay when connecting via ssh [SOLVED]

#3 2011-10-19 13:52:23

Re: delay when connecting via ssh [SOLVED]

#4 2011-10-19 14:00:32

Re: delay when connecting via ssh [SOLVED]

#5 2011-10-19 14:56:38

Re: delay when connecting via ssh [SOLVED]

#6 2011-10-19 15:29:14

Re: delay when connecting via ssh [SOLVED]

#7 2011-10-19 17:33:54

Re: delay when connecting via ssh [SOLVED]

#8 2011-10-19 18:40:15

Re: delay when connecting via ssh [SOLVED]

#9 2011-10-19 19:14:01

Re: delay when connecting via ssh [SOLVED]

#10 2011-10-19 19:20:23

Re: delay when connecting via ssh [SOLVED]

Board footer