ssh initial connects SLOW - SSH

This is a discussion on ssh initial connects SLOW - SSH ; I have a strange thing going on with ssh. I have two systems on my local LAN, one a Fedora Core 6 system and one a Fedora (Core) 8. Until about a week ago, I was able to ssh between ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: ssh initial connects SLOW

  1. ssh initial connects SLOW

    I have a strange thing going on with ssh. I have two systems on my
    local LAN, one a Fedora Core 6 system and one a Fedora (Core) 8.

    Until about a week ago, I was able to ssh between these two systems
    without any problem whatsoever. However, for the last few days, when
    I ssh in from one to the other (in either direction), it takes an
    inordinate amount of time (> 1 minute) for the ssh command to complete
    and yield control back to the terminal.

    Any ideas why this is happening? The network between the two computers
    seems to be just fine. One is connected via 802.11g with WEP security
    enabled, and always has been, i.e., nothing changed here between the
    time it was working and the time it stopped working.

    [yates@localhost ~]$ uname -a
    Linux localhost.localdomain 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:36 EST 2007 x86_64 x86_64 x86_64 GNU/Linux


    [yates@localhost client]$ uname -a
    Linux localhost.localdomain 2.6.22.14-72.fc6 #1 SMP Wed Nov 21 14:10:25 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
    --
    % Randy Yates % "So now it's getting late,
    %% Fuquay-Varina, NC % and those who hesitate
    %%% 919-577-9882 % got no one..."
    %%%% % 'Waterfall', *Face The Music*, ELO
    http://www.digitalsignallabs.com

  2. Re: ssh initial connects SLOW

    Randy Yates wrote:
    > I have a strange thing going on with ssh. I have two systems on my
    > local LAN, one a Fedora Core 6 system and one a Fedora (Core) 8.
    >
    > Until about a week ago, I was able to ssh between these two systems
    > without any problem whatsoever. However, for the last few days, when
    > I ssh in from one to the other (in either direction), it takes an
    > inordinate amount of time (> 1 minute) for the ssh command to complete
    > and yield control back to the terminal.
    >
    > Any ideas why this is happening? The network between the two computers
    > seems to be just fine. One is connected via 802.11g with WEP security
    > enabled, and always has been, i.e., nothing changed here between the
    > time it was working and the time it stopped working.
    >
    > [yates@localhost ~]$ uname -a
    > Linux localhost.localdomain 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:36 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
    >
    >
    > [yates@localhost client]$ uname -a
    > Linux localhost.localdomain 2.6.22.14-72.fc6 #1 SMP Wed Nov 21 14:10:25 EST 2007 x86_64 x86_64 x86_64 GNU/Linux


    Ahh. I think we need to say "welcome to reverse DNS". "localhost.localdomain" resolves to 127.0.0.1, which is *not* the IP address the connection is coming from. And when your SSH server looks up 192.168.1.3 or whatever your first localhost's IP address is, it gets a name that does not match. I suspect you've recently changed your DNS or /etc/hosts setups, or something else was poking your DNS so you had a cached "I don't know what that is!" result.

    This reverse DNS can be turned off by setting the sshd initscript to start sshd with "sshd -u0", a bit of old obscurity that says "don't record any more than 0 characters for the client hostname", and as it's programmed, prevents the reverse DNS lookup at all. There are security reasons and logging reasons that this is useful information, but if you don't have good DNS setups, you may want to disable it.

    There is no other graceful way to to turn this off: sshd_config does not support any options to disable it, and never has.

  3. Re: ssh initial connects SLOW

    Nico Kadel-Garcia writes:

    > Randy Yates wrote:
    >> I have a strange thing going on with ssh. I have two systems on my
    >> local LAN, one a Fedora Core 6 system and one a Fedora (Core) 8.
    >>
    >> Until about a week ago, I was able to ssh between these two systems
    >> without any problem whatsoever. However, for the last few days, when
    >> I ssh in from one to the other (in either direction), it takes an
    >> inordinate amount of time (> 1 minute) for the ssh command to complete
    >> and yield control back to the terminal.
    >>
    >> Any ideas why this is happening? The network between the two computers
    >> seems to be just fine. One is connected via 802.11g with WEP security
    >> enabled, and always has been, i.e., nothing changed here between the
    >> time it was working and the time it stopped working.
    >>
    >> [yates@localhost ~]$ uname -a
    >> Linux localhost.localdomain 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:36 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
    >>
    >>
    >> [yates@localhost client]$ uname -a
    >> Linux localhost.localdomain 2.6.22.14-72.fc6 #1 SMP Wed Nov 21 14:10:25 EST 2007 x86_64 x86_64 x86_64 GNU/Linux

    >
    > Ahh. I think we need to say "welcome to reverse DNS". "localhost.localdomain" resolves to 127.0.0.1, which is *not* the IP address the connection is coming from. And when your SSH server looks up 192.168.1.3 or whatever your first localhost's IP address is, it gets a name that does not match. I suspect you've recently changed your DNS or /etc/hosts setups, or something else was poking your DNS so you had a cached "I don't know what that is!" result.
    >
    > This reverse DNS can be turned off by setting the sshd initscript to start sshd with "sshd -u0", a bit of old obscurity that says "don't record any more than 0 characters for the client hostname", and as it's programmed, prevents the reverse DNS lookup at all. There are security reasons and logging reasons that this is useful information, but if you don't have good DNS setups, you may want to disable it.
    >
    > There is no other graceful way to to turn this off: sshd_config does
    > not support any options to disable it, and never has.


    Hi Nico,

    Thanks for responding and for this idea. Unfortunately, that wasn't
    it. I restarted the daemons on both computers and I still get the
    same problem.

    Also, since I'm using numeric IP addresses in the ssh command, e.g.,

    ssh -p 12345 192.168.1.101

    I don't understand why a reverse lookup would even be done.

    I subsequently had the idea that perhaps the key on one side, which
    might have been generated with a previous version of openssh, was
    somehow causing a problem with the possible new version (I "yum update"d
    a whole bunch of stuff on the Fedora 8 computer a couple of weeks ago
    and am not sure if openssh was on the list of updates or not). So I
    erased the authorized_keys, and also the known_hosts, files in both
    computers (in the .ssh subdirectory). Still no joy.

    Here's the result of running the ssh command with -vvv:

    [yates@localhost .ssh]$ ssh -vvv -p 12345 192.168.1.101
    OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to 192.168.1.101 [192.168.1.101] port 12345.
    debug1: Connection established.
    debug1: identity file /home/yates/.ssh/identity type -1
    debug3: Not a RSA1 key file /home/yates/.ssh/id_rsa.
    debug2: key_type_from_name: unknown key type '-----BEGIN'
    debug3: key_read: missing keytype
    debug2: key_type_from_name: unknown key type 'Proc-Type:'
    debug3: key_read: missing keytype
    debug2: key_type_from_name: unknown key type 'DEK-Info:'
    debug3: key_read: missing keytype
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug2: key_type_from_name: unknown key type '-----END'
    debug3: key_read: missing keytype
    debug1: identity file /home/yates/.ssh/id_rsa type 1
    debug1: identity file /home/yates/.ssh/id_dsa type -1
    debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7
    debug1: match: OpenSSH_4.7 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_4.3
    debug2: fd 3 setting O_NONBLOCK
    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
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,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: 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
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,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-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_init: found hmac-md5

    debug1: kex: server->client aes128-cbc hmac-md5 none
    debug2: mac_init: found hmac-md5
    debug1: kex: client->server aes128-cbc hmac-md5 none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug2: dh_gen_key: priv key bits set: 123/256
    debug2: bits set: 496/1024
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug3: check_host_in_hostfile: filename /home/yates/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 1
    debug1: Host '192.168.1.101' is known and matches the RSA host key.
    debug1: Found key in /home/yates/.ssh/known_hosts:1
    debug2: bits set: 500/1024
    debug1: ssh_rsa_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: SSH2_MSG_SERVICE_REQUEST sent
    debug2: service_accept: ssh-userauth
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug2: key: /home/yates/.ssh/id_rsa (0x5555557b20a0)
    debug2: key: /home/yates/.ssh/identity ((nil))
    debug2: key: /home/yates/.ssh/id_dsa ((nil))
    debug1: Authentications that can continue: publickey,gssapi-with-mic,password
    debug3: start over, passed a different list publickey,gssapi-with-mic,password
    debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
    debug3: authmethod_lookup gssapi-with-mic
    debug3: remaining preferred: publickey,keyboard-interactive,password
    debug3: authmethod_is_enabled gssapi-with-mic
    debug1: Next authentication method: gssapi-with-mic
    debug3: Trying to reverse map address 192.168.1.101.
    debug1: An invalid name was supplied
    Unknown code krb5 243

    debug1: An invalid name was supplied
    Unknown code krb5 243

    debug1: An invalid name was supplied
    Unknown code krb5 243

    debug2: we did not send a packet, disable method
    debug3: authmethod_lookup publickey
    debug3: remaining preferred: keyboard-interactive,password
    debug3: authmethod_is_enabled publickey
    debug1: Next authentication method: publickey
    debug1: Offering public key: /home/yates/.ssh/id_rsa
    debug3: send_pubkey_test
    debug2: we sent a publickey packet, wait for reply
    debug1: Server accepts key: pkalg ssh-rsa blen 277
    debug2: input_userauth_pk_ok: fp 81:32:a3:c9:cc:1c:08:5c:3e:4a:d7:a5:2f:bd:db:65
    debug3: sign_and_send_pubkey
    debug1: Authentication succeeded (publickey).
    debug1: channel 0: new [client-session]
    debug3: ssh_session2_open: channel_new: 0
    debug2: channel 0: send open
    debug1: Entering interactive session.
    debug2: callback start
    debug2: client_session2_setup: id 0
    debug2: channel 0: request pty-req confirm 0
    debug3: tty_make_modes: ospeed 38400
    debug3: tty_make_modes: ispeed 38400
    debug3: tty_make_modes: 1 3
    debug3: tty_make_modes: 2 28
    debug3: tty_make_modes: 3 127
    debug3: tty_make_modes: 9 19
    debug3: tty_make_modes: 10 26
    debug3: tty_make_modes: 12 18
    debug3: tty_make_modes: 13 23
    debug3: tty_make_modes: 14 22
    debug3: tty_make_modes: 18 15
    debug3: tty_make_modes: 30 0
    debug3: tty_make_modes: 31 0
    debug3: tty_make_modes: 32 0
    debug3: tty_make_modes: 33 0
    debug3: tty_make_modes: 34 0
    debug3: tty_make_modes: 35 0
    debug3: tty_make_modes: 36 1
    debug3: tty_make_modes: 37 0
    debug3: tty_make_modes: 38 1
    debug3: tty_make_modes: 39 0
    debug3: tty_make_modes: 40 0
    debug3: tty_make_modes: 41 0
    debug3: tty_make_modes: 50 1
    debug3: tty_make_modes: 51 1
    debug3: tty_make_modes: 52 0
    debug3: tty_make_modes: 53 1
    debug3: tty_make_modes: 54 1
    debug3: tty_make_modes: 55 1
    debug3: tty_make_modes: 56 0
    debug3: tty_make_modes: 57 0
    debug3: tty_make_modes: 58 0
    debug3: tty_make_modes: 59 1
    debug3: tty_make_modes: 60 1
    debug3: tty_make_modes: 61 1
    debug3: tty_make_modes: 62 0
    debug3: tty_make_modes: 70 1
    debug3: tty_make_modes: 71 0
    debug3: tty_make_modes: 72 1
    debug3: tty_make_modes: 73 0
    debug3: tty_make_modes: 74 0
    debug3: tty_make_modes: 75 0
    debug3: tty_make_modes: 90 1
    debug3: tty_make_modes: 91 1
    debug3: tty_make_modes: 92 0
    debug3: tty_make_modes: 93 0
    debug1: Sending environment.
    debug3: Ignored env OTHER_JVM_BINDIR
    debug3: Ignored env SSH_AGENT_PID
    debug3: Ignored env HOSTNAME
    debug3: Ignored env DSLDSPROOTDIR
    debug3: Ignored env DSPTEXMFHOME
    debug3: Ignored env TERM
    debug3: Ignored env SHELL
    debug3: Ignored env HISTSIZE
    debug3: Ignored env KDE_NO_IPV6
    debug3: Ignored env DSLTEXMFHOME
    debug3: Ignored env GTK_RC_FILES
    debug3: Ignored env WINDOWID
    debug3: Ignored env OLDPWD
    debug3: Ignored env QTDIR
    debug3: Ignored env QTINC
    debug3: Ignored env XTERM_SHELL
    debug3: Ignored env USER
    debug3: Ignored env YATESTEXMFHOME
    debug3: Ignored env LS_COLORS
    debug3: Ignored env GNOME_KEYRING_SOCKET
    debug3: Ignored env SSH_AUTH_SOCK
    debug3: Ignored env KDEDIR
    debug3: Ignored env SESSION_MANAGER
    debug3: Ignored env PATH
    debug3: Ignored env DESKTOP_SESSION
    debug3: Ignored env MAIL
    debug3: Ignored env GDM_XSERVER_LOCATION
    debug3: Ignored env PWD
    debug3: Ignored env INPUTRC
    debug3: Ignored env XMODIFIERS
    debug3: Ignored env EDITOR
    debug1: Sending env LANG = en_US.UTF-8
    debug2: channel 0: request env confirm 0
    debug3: Ignored env KDE_IS_PRELINKED
    debug3: Ignored env GDMSESSION
    debug3: Ignored env XTERM_VERSION
    debug3: Ignored env SSH_ASKPASS
    debug3: Ignored env SHLVL
    debug3: Ignored env HOME
    debug3: Ignored env GNOME_DESKTOP_SESSION_ID
    debug3: Ignored env LOGNAME
    debug3: Ignored env BTSCDECODER_ROOT_DIR
    debug3: Ignored env CVS_RSH
    debug3: Ignored env QTLIB
    debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
    debug3: Ignored env LESSOPEN
    debug3: Ignored env DISPLAY
    debug3: Ignored env G_BROKEN_FILENAMES
    debug3: Ignored env XAUTHORITY
    debug3: Ignored env EDUTEXMFHOME
    debug3: Ignored env _
    debug2: channel 0: request shell confirm 0
    debug2: fd 3 setting TCP_NODELAY
    debug2: callback done
    debug2: channel 0: open confirm rwindow 0 rmax 32768
    debug2: channel 0: rcvd adjust 131072
    -- Last login: Sun Jan 20 09:36:11 2008 from 192.168.1.103
    [yates@localhost ~]$ debug2: client_check_window_change: changed
    debug2: channel 0: request window-change confirm 0
    [yates@localhost ~]$ debug2: client_check_window_change: changed
    debug2: channel 0: request window-change confirm 0
    [yates@localhost ~]$ debug2: client_check_window_change: changed
    debug2: channel 0: request window-change confirm 0
    debug2: client_check_window_change: changed
    debug2: channel 0: request window-change confirm 0
    debug2: client_check_window_change: changed
    debug2: channel 0: request window-change confirm 0
    debug2: client_check_window_change: changed
    debug2: channel 0: request window-change confirm 0
    debug2: client_check_window_change: changed
    debug2: channel 0: request window-change confirm 0
    debug2: client_check_window_change: changed
    debug2: channel 0: request window-change confirm 0
    debug2: client_check_window_change: changed
    debug2: channel 0: request window-change confirm 0
    debug2: client_check_window_change: changed
    debug2: channel 0: request window-change confirm 0
    debug2: client_check_window_change: changed
    debug2: channel 0: request window-change confirm 0

    % Randy Yates % "How's life on earth?
    %% Fuquay-Varina, NC % ... What is it worth?"
    %%% 919-577-9882 % 'Mission (A World Record)',
    %%%% % *A New World Record*, ELO
    http://www.digitalsignallabs.com

  4. Re: ssh initial connects SLOW

    Randy Yates writes:
    > [...]


    Problem solved. In reading the -vvv output I posted, I realized the
    client was attempting the GSSI... authentication method first, then
    publickeys. In reading the man page for ssh, there is a
    PreferredAuthentications option that can be set in
    ssh_config. Enteringthe following line in /etc/ssh/ssh_config,

    PreferredAuthentications publickey,hostbased,keyboard-interactive,password

    (on both sides) solved the problem.
    --
    % Randy Yates % "The dreamer, the unwoken fool -
    %% Fuquay-Varina, NC % in dreams, no pain will kiss the brow..."
    %%% 919-577-9882 %
    %%%% % 'Eldorado Overture', *Eldorado*, ELO
    http://www.digitalsignallabs.com

  5. Re: ssh initial connects SLOW

    Randy Yates writes:

    > Randy Yates writes:
    >> [...]

    >
    > Problem solved. In reading the -vvv output I posted, I realized the
    > client was attempting the GSSI... authentication method first, then
    > publickeys. In reading the man page for ssh, there is a
    > PreferredAuthentications option that can be set in
    > ssh_config. Enteringthe following line in /etc/ssh/ssh_config,
    >
    > PreferredAuthentications publickey,hostbased,keyboard-interactive,password
    >
    > (on both sides) solved the problem.


    Note that the reason WHY the authentication order changed ON BOTH SIDES
    is still a mystery. Perhaps I yum updated both sides' openssh
    applications without realizing it recently, and the default
    authentication order changed between the old openssh and the new.
    --
    % Randy Yates % "Bird, on the wing,
    %% Fuquay-Varina, NC % goes floating by
    %%% 919-577-9882 % but there's a teardrop in his eye..."
    %%%% % 'One Summer Dream', *Face The Music*, ELO
    http://www.digitalsignallabs.com

  6. Re: ssh initial connects SLOW

    Randy Yates wrote:
    > Randy Yates writes:
    >
    >> Randy Yates writes:
    >>> [...]

    >> Problem solved. In reading the -vvv output I posted, I realized the
    >> client was attempting the GSSI... authentication method first, then
    >> publickeys. In reading the man page for ssh, there is a
    >> PreferredAuthentications option that can be set in
    >> ssh_config. Enteringthe following line in /etc/ssh/ssh_config,
    >>
    >> PreferredAuthentications publickey,hostbased,keyboard-interactive,password
    >>
    >> (on both sides) solved the problem.

    >
    > Note that the reason WHY the authentication order changed ON BOTH SIDES
    > is still a mystery. Perhaps I yum updated both sides' openssh
    > applications without realizing it recently, and the default
    > authentication order changed between the old openssh and the new.


    Did you have an "/etc/ssh/ssh_config.rpmsave" lying around? And /var/log/rpmpkgs* should reveal any changes in your packages over the last few days.

  7. Re: ssh initial connects SLOW

    Nico Kadel-Garcia writes:

    > Randy Yates wrote:
    >> Randy Yates writes:
    >>
    >>> Randy Yates writes:
    >>>> [...]
    >>> Problem solved. In reading the -vvv output I posted, I realized the
    >>> client was attempting the GSSI... authentication method first, then
    >>> publickeys. In reading the man page for ssh, there is a
    >>> PreferredAuthentications option that can be set in
    >>> ssh_config. Enteringthe following line in /etc/ssh/ssh_config,
    >>>
    >>> PreferredAuthentications publickey,hostbased,keyboard-interactive,password
    >>>
    >>> (on both sides) solved the problem.

    >>
    >> Note that the reason WHY the authentication order changed ON BOTH SIDES
    >> is still a mystery. Perhaps I yum updated both sides' openssh
    >> applications without realizing it recently, and the default
    >> authentication order changed between the old openssh and the new.

    >
    > Did you have an "/etc/ssh/ssh_config.rpmsave" lying around?


    No.

    > And /var/log/rpmpkgs* should reveal any changes in your packages over
    > the last few days.


    Those files seem to list every package that is installed. Diffing
    between two versions of the does not reveal an ssh update either.
    --
    % Randy Yates % "Bird, on the wing,
    %% Fuquay-Varina, NC % goes floating by
    %%% 919-577-9882 % but there's a teardrop in his eye..."
    %%%% % 'One Summer Dream', *Face The Music*, ELO
    http://www.digitalsignallabs.com

  8. Re: ssh initial connects SLOW

    Randy Yates wrote:
    > Nico Kadel-Garcia writes:
    >
    >> Randy Yates wrote:
    >>> I have a strange thing going on with ssh. I have two systems on my
    >>> local LAN, one a Fedora Core 6 system and one a Fedora (Core) 8.
    >>>
    >>> Until about a week ago, I was able to ssh between these two systems
    >>> without any problem whatsoever. However, for the last few days, when
    >>> I ssh in from one to the other (in either direction), it takes an
    >>> inordinate amount of time (> 1 minute) for the ssh command to complete
    >>> and yield control back to the terminal.
    >>>
    >>> Any ideas why this is happening? The network between the two computers
    >>> seems to be just fine. One is connected via 802.11g with WEP security
    >>> enabled, and always has been, i.e., nothing changed here between the
    >>> time it was working and the time it stopped working.
    >>>
    >>> [yates@localhost ~]$ uname -a
    >>> Linux localhost.localdomain 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:36 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
    >>>
    >>>
    >>> [yates@localhost client]$ uname -a
    >>> Linux localhost.localdomain 2.6.22.14-72.fc6 #1 SMP Wed Nov 21 14:10:25 EST 2007 x86_64 x86_64 x86_64 GNU/Linux

    >> Ahh. I think we need to say "welcome to reverse DNS". "localhost.localdomain" resolves to 127.0.0.1, which is *not* the IP address the connection is coming from. And when your SSH server looks up 192.168.1.3 or whatever your first localhost's IP address is, it gets a name that does not match. I suspect you've recently changed your DNS or /etc/hosts setups, or something else was poking your DNS so you had a cached "I don't know what that is!" result.
    >>
    >> This reverse DNS can be turned off by setting the sshd initscript to start sshd with "sshd -u0", a bit of old obscurity that says "don't record any more than 0 characters for the client hostname", and as it's programmed, prevents the reverse DNS lookup at all. There are security reasons and logging reasons that this is useful information, but if you don't have good DNS setups, you may want to disable it.
    >>
    >> There is no other graceful way to to turn this off: sshd_config does
    >> not support any options to disable it, and never has.

    >
    > Hi Nico,
    >
    > Thanks for responding and for this idea. Unfortunately, that wasn't
    > it. I restarted the daemons on both computers and I still get the
    > same problem.
    >
    > Also, since I'm using numeric IP addresses in the ssh command, e.g.,
    >
    > ssh -p 12345 192.168.1.101
    >
    > I don't understand why a reverse lookup would even be done.


    This is an *OLD* issue. The SSH daemon does a lookup of the hostname via which you connect to see if it has a matching IP address and reverse DNS lookup, in order primarily to do logging of what host the client came from. In a dynamic DNS environment, this is particularly tricky to log correctly, so it tries to find out what DNS thinks the host is. And it's possible, in some screwed up DNS environments, to register a hostname of "192.168.1.101", or to put it in /etc/hosts to point actually to something else.

    Thus, SSH does a reverse DNS lookup to keep these things straight.

  9. Re: ssh initial connects SLOW

    On 2008-01-20, Nico Kadel-Garcia wrote:
    > Randy Yates wrote:

    [...]
    > This is an *OLD* issue. The SSH daemon does a lookup of the hostname
    > via which you connect to see if it has a matching IP address and reverse
    > DNS lookup, in order primarily to do logging of what host the client came
    > from. In a dynamic DNS environment, this is particularly tricky to log
    > correctly, so it tries to find out what DNS thinks the host is. And it's
    > possible, in some screwed up DNS environments, to register a hostname
    > of "192.168.1.101", or to put it in /etc/hosts to point actually to
    > something else.


    Depending on exactly what's triggering the DNS reverse lookup on the
    server, you can disable it with "UseDNS no" in sshd_config.

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

  10. Re: ssh initial connects SLOW

    On 24 Jan, 23:31, Darren Tucker wrote:
    > On 2008-01-20, Nico Kadel-Garcia wrote:
    >
    > > Randy Yates wrote:

    > [...]
    > > This is an *OLD* issue. The SSH daemon does a lookup of the hostname
    > > via which you connect to see if it has a matching IP address and reverse
    > > DNS lookup, in order primarily to do logging of what host the client came
    > > from. In a dynamic DNS environment, this is particularly tricky to log
    > > correctly, so it tries to find out what DNS thinks the host is. And it's
    > > possible, in some screwed up DNS environments, to register a hostname
    > > of "192.168.1.101", or to put it in /etc/hosts to point actually to
    > > something else.

    >
    > Depending on exactly what's triggering the DNS reverse lookup on the
    > server, you can disable it with "UseDNS no" in sshd_config.


    If I remember the source code correctly, this does not block the
    attempted *logging* of the hostname of the connecting site, and thus
    this option doesn't actually stop the lookup. But modifying the init
    script to use "sshd -u0" to set the length of the recorded hostname
    information ot 0 does, in fact, block the lookup. This is well
    documented in the sshd manpage.

    I don't have a source tree in my hands at the moment to verify it: it
    would have been easy to modify the code to check for the UseDNS
    setting and skip it entirely, but I'm surprised if that change has
    occurred since the last time I looked.

  11. Re: ssh initial connects SLOW

    On 25 Jan, 01:10, Nico Kadel-Garcia wrote:
    > On 24 Jan, 23:31, Darren Tucker wrote:
    >
    > > On 2008-01-20, Nico Kadel-Garcia wrote:

    >
    > > > Randy Yates wrote:

    > > [...]
    > > > This is an *OLD* issue. The SSH daemon does a lookup of the hostname
    > > > via which you connect to see if it has a matching IP address and reverse
    > > > DNS lookup, in order primarily to do logging of what host the client came
    > > > from. In a dynamic DNS environment, this is particularly tricky to log
    > > > correctly, so it tries to find out what DNS thinks the host is. And it's
    > > > possible, in some screwed up DNS environments, to register a hostname
    > > > of "192.168.1.101", or to put it in /etc/hosts to point actually to
    > > > something else.

    >
    > > Depending on exactly what's triggering the DNS reverse lookup on the
    > > server, you can disable it with "UseDNS no" in sshd_config.

    >
    > If I remember the source code correctly, this does not block the
    > attempted *logging* of the hostname of the connecting site, and thus
    > this option doesn't actually stop the lookup. But modifying the init
    > script to use "sshd -u0" to set the length of the recorded hostname
    > information ot 0 does, in fact, block the lookup. This is well
    > documented in the sshd manpage.
    >
    > I don't have a source tree in my hands at the moment to verify it: it
    > would have been easy to modify the code to check for the UseDNS
    > setting and skip it entirely, but I'm surprised if that change has
    > occurred since the last time I looked.


    Found it: around line 66 in canohost.c. Yes, it does a reverse DNS
    *twice*, and skips theh *secondI* one if UseDNS is turned off.


  12. Re: ssh initial connects SLOW

    On 2008-01-25, Nico Kadel-Garcia wrote:
    > On 25 Jan, 01:10, Nico Kadel-Garcia wrote:
    >> On 24 Jan, 23:31, Darren Tucker wrote:

    [...]
    >> > Depending on exactly what's triggering the DNS reverse lookup on the
    >> > server, you can disable it with "UseDNS no" in sshd_config.

    >>
    >> If I remember the source code correctly, this does not block the
    >> attempted *logging* of the hostname of the connecting site, and thus
    >> this option doesn't actually stop the lookup. But modifying the init
    >> script to use "sshd -u0" to set the length of the recorded hostname
    >> information ot 0 does, in fact, block the lookup. This is well
    >> documented in the sshd manpage.
    >>
    >> I don't have a source tree in my hands at the moment to verify it: it
    >> would have been easy to modify the code to check for the UseDNS
    >> setting and skip it entirely, but I'm surprised if that change has
    >> occurred since the last time I looked.

    >
    > Found it: around line 66 in canohost.c. Yes, it does a reverse DNS
    > *twice*, and skips theh *secondI* one if UseDNS is turned off.


    That first getnameinfo call in get_remote_hostname has the NI_NUMERICHOST
    flag set (to render the sockaddr into a human-readable numeric string)
    which should not cause a DNS lookup. The one after the use_dns test has
    NI_NAMEREQD so it will cause a lookup but only if UseDNS is set.

    Some of the components sshd uses might do their own lookup though (eg
    PAM, tcpwrappers) regardless of the UseDNS setting. If sshd itself is
    generating a lookup with UseDNS=no then that's probably a bug that
    should be fixed, and I would be interested to hear about it.

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

+ Reply to Thread