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

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.

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.

Did you try sshd -u0 ?

>>>>> "DK" == David Kelly <n4hhe@Yahoo.com> 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

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.

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.

In article <1164673268.074005.315100@n67g2000cwd.googlegroups .com>
"Nico" <nkadel@gmail.com> 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

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)