3

I'm having issues while connecting to my Local Centos 6.3 VM with 500 MB ram.

Below is the output of ssh -vvv localhost connection:

OpenSSH_6.3, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /usr/local/etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 22.
^^^^^^^^^^ Loading this statement takes more than a minute

debug1: Connection established.
...

debug1: Next authentication method: password 
root@localhost's password:
^^^^^^^^^^ This step takes a minute too

debug3: packet_send2: adding 64 (len 50 padlen 14 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to localhost ([127.0.0.1]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
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  9 13:27:02 2013 from 10.0.0.2

Please suggest on how do I get rid of this delay.

peterph
  • 30,838
Avinash
  • 403

2 Answers2

3

My guess is, that the problem are DNS requests timeouts. Try connecting by IP address instead of hostname and turning off the UseDNS option on the server you are connecting to. Other than that:

  1. assuming you are connecting there from the VM host, I would expect ssh localhost to connect to the host, not to the guest VM. Unless you have some interesting network setup, of course.

  2. for the first delay you may want to run it in strace and check what system call is the ssh client hanging in.

  3. for the second delay, run top in the VM to see what is going on there while you are connecting to it. At the same time I suggest running the SSH daemon in debug mode on an alternative port and connecting to that instance - you'll see where it is waiting - just run (as root):

    sshd -ddd -p 2222 -o UsePrivilegeSeparation=no

    this will start the SSH daemon on port 2222, log lots of information (-ddd) and won't use privilege separation during logging in (Disabling privilege separation will make it easier to see what is happening in strace, since only one process will be used). You can also add -o UseDNS=no to disable the option mentioned above.

kurtm
  • 7,055
peterph
  • 30,838
  • Not using privilege separation? What's the purpose in context of this question? – jirib Oct 09 '13 at 09:42
  • @JiriXichtkniha if the next step is strace sshd ... then it'll be much easier to debug things with only one process involved. – peterph Oct 09 '13 at 09:52
0

If it's a VM, it could be due to insufficient entropy. Use this line to monitor the available entropy before/during your connection attempt:

while true; do sleep 5; cat /proc/sys/kernel/random/entropy_avail; done

If it is already quite low or decreases significantly during the connection attempt, it is very likely the culprit.

EDIT: Doing this affects the available entropy itself, as starting new processes consumes entropy. See also https://blog.flameeyes.eu/2011/03/entropy-broken

You can increase the available entropy by either installing a daemon (rng-tools or clrngd) which tries to gather more entropy or make sure, your VM has a proper entropy device assigned which depends on your virtualization solution.

Elias Probst
  • 1,053