Time to connect to a freebsd box - SSH

This is a discussion on Time to connect to a freebsd box - SSH ; Hello, I am using ssh on serveral computers here, one linuxbox, one OSXbox and one freebsdbox. When i connect to the freebsdbox, it takes a very long time (about 1 min) to establish the connection. Therefor i tried ssh -vvv ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Time to connect to a freebsd box

  1. Time to connect to a freebsd box

    Hello,
    I am using ssh on serveral computers here, one linuxbox, one OSXbox and
    one freebsdbox. When i connect to the freebsdbox, it takes a very long
    time (about 1 min) to establish the connection. Therefor i tried

    ssh -vvv user@freebsdbox

    and got the following output:

    ================================================== ==================
    PBook:~ wolfgang$ ssh -vvv wolfgang@192.168.1.100
    OpenSSH_4.2p1, OpenSSL 0.9.7i 14 Oct 2005
    debug1: Reading configuration data /Users/wolfgang/.ssh/config
    debug1: Reading configuration data /etc/ssh_config
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to 192.168.1.100 [192.168.1.100] port 22.
    debug1: Connection established.
    ================================================== ==================
    to this point, it took about 1 sec, but then nothing happend for al long
    time
    ================================================== ==================
    debug1: identity file /Users/wolfgang/.ssh/identity type -1
    debug1: identity file /Users/wolfgang/.ssh/id_rsa type -1
    debug3: Not a RSA1 key file /Users/wolfgang/.ssh/id_dsa.
    debug2: key_type_from_name: unknown key type '-----BEGIN'
    ================================================== ==================
    what is going on here? I just used the standard output from OpenSSH
    ================================================== ==================
    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
    debug2: key_type_from_name: unknown key type '-----END'
    debug3: key_read: missing keytype
    debug1: identity file /Users/wolfgang/.ssh/id_dsa type 2
    debug1: Remote protocol version 2.0, remote software version
    OpenSSH_4.2p1 FreeBSD-20050903
    debug1: match: OpenSSH_4.2p1 FreeBSD-20050903 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_4.2
    debug2: fd 3 setting O_NONBLOCK
    debug1: Miscellaneous failure
    No credentials cache found

    debug1: Miscellaneous failure
    No credentials cache found

    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-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: 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
    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: 129/256
    debug2: bits set: 524/1024
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug3: check_host_in_hostfile: filename /Users/wolfgang/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 7
    debug1: Host '192.168.1.100' is known and matches the DSA host key.
    debug1: Found key in /Users/wolfgang/.ssh/known_hosts:7
    debug2: bits set: 524/1024
    debug1: ssh_dss_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: /Users/wolfgang/.ssh/identity (0x0)
    debug2: key: /Users/wolfgang/.ssh/id_rsa (0x0)
    debug2: key: /Users/wolfgang/.ssh/id_dsa (0x300d50)
    debug1: Authentications that can continue:
    ================================================== ==================
    it takes up to here, to find out my key? Is there some way, to make this
    faster/shorter?
    ================================================== ==================
    publickey,keyboard-interactive
    debug3: start over, passed a different list publickey,keyboard-interactive
    debug3: preferred
    gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
    debug3: authmethod_lookup publickey
    debug3: remaining preferred: keyboard-interactive,password
    debug3: authmethod_is_enabled publickey
    debug1: Next authentication method: publickey
    debug1: Trying private key: /Users/wolfgang/.ssh/identity
    debug3: no such identity: /Users/wolfgang/.ssh/identity
    debug1: Trying private key: /Users/wolfgang/.ssh/id_rsa
    debug3: no such identity: /Users/wolfgang/.ssh/id_rsa
    debug1: Offering public key: /Users/wolfgang/.ssh/id_dsa
    debug3: send_pubkey_test
    debug2: we sent a publickey packet, wait for reply
    debug1: Server accepts key: pkalg ssh-dss blen 434
    debug2: input_userauth_pk_ok: fp
    2d:83:10:86:f1:97:13:99:d3:c3:b1:cf:51:e7:00:4d
    debug3: sign_and_send_pubkey
    debug1: read PEM private key done: type DSA
    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 9600
    debug3: tty_make_modes: ispeed 9600
    debug3: tty_make_modes: 1 3
    debug3: tty_make_modes: 2 28
    debug3: tty_make_modes: 3 127
    debug3: tty_make_modes: 4 21
    debug3: tty_make_modes: 5 4
    debug3: tty_make_modes: 6 255
    debug3: tty_make_modes: 7 255
    debug3: tty_make_modes: 8 17
    debug3: tty_make_modes: 9 19
    debug3: tty_make_modes: 10 26
    debug3: tty_make_modes: 11 25
    debug3: tty_make_modes: 12 18
    debug3: tty_make_modes: 13 23
    debug3: tty_make_modes: 14 22
    debug3: tty_make_modes: 17 20
    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: 38 1
    debug3: tty_make_modes: 39 1
    debug3: tty_make_modes: 40 0
    debug3: tty_make_modes: 41 1
    debug3: tty_make_modes: 50 1
    debug3: tty_make_modes: 51 1
    debug3: tty_make_modes: 53 1
    debug3: tty_make_modes: 54 1
    debug3: tty_make_modes: 55 0
    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 1
    debug3: tty_make_modes: 70 1
    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
    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: Fri Nov 10 10:59:06 2006 from 192.168.1.10
    ================================================== ==================

    maybe, someone can tell me, what the interesting lines in the output
    above are. And maybe, someone can tell me, why this is so slow on this
    machine.

    Thank you for every hint
    Wolfgang

  2. Re: Time to connect to a freebsd box


    Wolfgang Meiners wrote:
    > Hello,
    > I am using ssh on serveral computers here, one linuxbox, one OSXbox and
    > one freebsdbox. When i connect to the freebsdbox, it takes a very long
    > time (about 1 min) to establish the connection. Therefor i tried


    Is the FreeBSD box overloaded? And does your client show up in forward
    and reverse DNS for the FreeBSD box? The almost mandatory DNS and
    reverse DNS lookups for connecting clients can cause significant delays.


  3. Re: Time to connect to a freebsd box

    Nico wrote:
    > Wolfgang Meiners wrote:
    >> Hello,
    >> I am using ssh on serveral computers here, one linuxbox, one OSXbox and
    >> one freebsdbox. When i connect to the freebsdbox, it takes a very long
    >> time (about 1 min) to establish the connection. Therefor i tried

    >
    > Is the FreeBSD box overloaded? And does your client show up in forward
    > and reverse DNS for the FreeBSD box? The almost mandatory DNS and
    > reverse DNS lookups for connecting clients can cause significant delays.


    I agree. Have found the FreeBSD sshd insists on doing reverse DNS
    lookups no matter what I have tried in /etc/ssh/sshd_config. Using
    Google suggests this situation is not unusual for others with Linux.

    A properly functioning local caching named cut inside ssh connection
    time down from 30 seconds to 5 seconds. FreeBSD 5.5-Stable on PII-450,
    Mac OS X, 192.168.0.0/24, both on the same 10/100 network switch.

  4. Re: Time to connect to a freebsd box


    Did you try sshd -u0 ?

    >>>>> "DK" == David Kelly writes:


    DK> Nico wrote:
    >> Wolfgang Meiners wrote:
    >>> Hello, I am using ssh on serveral computers here, one linuxbox,
    >>> one OSXbox and one freebsdbox. When i connect to the freebsdbox,
    >>> it takes a very long time (about 1 min) to establish the
    >>> connection. Therefor i tried

    >> Is the FreeBSD box overloaded? And does your client show up in
    >> forward and reverse DNS for the FreeBSD box? The almost mandatory
    >> DNS and reverse DNS lookups for connecting clients can cause
    >> significant delays.


    DK> I agree. Have found the FreeBSD sshd insists on doing reverse DNS
    DK> lookups no matter what I have tried in /etc/ssh/sshd_config. Using
    DK> Google suggests this situation is not unusual for others with
    DK> Linux.

    DK> A properly functioning local caching named cut inside ssh
    DK> connection time down from 30 seconds to 5 seconds. FreeBSD
    DK> 5.5-Stable on PII-450, Mac OS X, 192.168.0.0/24, both on the same
    DK> 10/100 network switch.

    --
    Richard Silverman
    res@qoxp.net


  5. Re: Time to connect to a freebsd box

    Richard E. Silverman wrote:
    > Did you try sshd -u0 ?


    Yes. No better.

    The only thing which worked was to define a local domain in named. I
    didn't explore expansion of /etc/hosts as I felt a local caching name
    server was something other machines on our inside network would benefit.

    In years past simply listing clients one wishes to connect from in
    /etc/hosts was enough to pacify sshd on FreeBSD. As I said above, didn't
    try that this time.

  6. Re: Time to connect to a freebsd box


    David Kelly wrote:
    > Richard E. Silverman wrote:
    > > Did you try sshd -u0 ?

    >
    > Yes. No better.
    >
    > The only thing which worked was to define a local domain in named. I
    > didn't explore expansion of /etc/hosts as I felt a local caching name
    > server was something other machines on our inside network would benefit.
    >
    > In years past simply listing clients one wishes to connect from in
    > /etc/hosts was enough to pacify sshd on FreeBSD. As I said above, didn't
    > try that this time.


    I'm really startled that starting the daemon with "sshd -u0" didn't
    work for you: that hack has worked for quite somem time. Of course,
    FreeBSD is its own support adventure, so it's conceivable something odd
    was introduced.

    It's not a hard bit to patch and disable, it's just irksome in
    environments where reverse DNS is unreliable or unavailable as a matter
    of policy.


  7. Re: Time to connect to a freebsd box

    In article <1164673268.074005.315100@n67g2000cwd.googlegroups. com>
    "Nico" writes:
    >
    >David Kelly wrote:
    >> Richard E. Silverman wrote:
    >> > Did you try sshd -u0 ?

    >>
    >> Yes. No better.
    >>
    >> The only thing which worked was to define a local domain in named. I
    >> didn't explore expansion of /etc/hosts as I felt a local caching name
    >> server was something other machines on our inside network would benefit.
    >>
    >> In years past simply listing clients one wishes to connect from in
    >> /etc/hosts was enough to pacify sshd on FreeBSD. As I said above, didn't
    >> try that this time.

    >
    >I'm really startled that starting the daemon with "sshd -u0" didn't
    >work for you: that hack has worked for quite somem time. Of course,
    >FreeBSD is its own support adventure, so it's conceivable something odd
    >was introduced.


    Well, there are some changes relative to the "standard" portable OpenSSH
    in the version that is in the FreeBSD base system (likewise in some
    Linux distributions, I would guess), but I don't think changing the
    semantics of -u is among them. Most likely culprit is tcp_wrappers -
    i.e. the FreeBSD version is built with the (standard OpenSSH) libwrap
    support enabled (likewise in most Linux distributions, I would guess),
    and libwrap is very fond of doing DNS lookups - maybe to the point of
    doing them even if you don't have anything in hosts.allow/deny that
    requires them.

    --Per Hedeland
    per@hedeland.org

  8. Re: Time to connect to a freebsd box

    Nico schrieb:
    > Wolfgang Meiners wrote:
    >> Hello,
    >> I am using ssh on serveral computers here, one linuxbox, one OSXbox and
    >> one freebsdbox. When i connect to the freebsdbox, it takes a very long
    >> time (about 1 min) to establish the connection. Therefor i tried

    >
    > Is the FreeBSD box overloaded? And does your client show up in forward
    > and reverse DNS for the FreeBSD box? The almost mandatory DNS and
    > reverse DNS lookups for connecting clients can cause significant delays.
    >


    Hello Nico,
    after a long time, i discovered your answer and the following thread.
    This lead me to the idea, to put the line

    UseDNS no

    into the sshd_config. This worked!
    Thank you and the others for information

    Wolfgang
    (hope, my english is not to bad)

+ Reply to Thread