SEO

Hi,

I have been pestered with this issue for quite some while (IIRC ever since
using 2.7 or 2.9 or so). The problem is that connecting with ssh to my P120
with 48MB of RAM takes up to about 30 seconds, but no shorter than 20
seconds. Version 2.6 used to take no longer than about 5 or 10 seconds.

I read a lot about DNS being the issue, but reversed lookup seems to be
fine. I ran sshd in debug mode and was wondering whether anyone could shed
some light on my issue. Maybe it is a question of using a different
authentication cypher? The longest stall occurs during negotiation of the
SSH2_MSG_KEX_DH_GEX_* messages.

Thank you for your time,

Martijn

SERVER SIDE (STALL 0 is not an issue, because it happens only at startup of
the daemon):

% sshd -d -p 2222
debug1: sshd version OpenSSH_3.6
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: Bind to port 2222 on ::.
Server listening on :: port 2222.
debug1: Bind to port 2222 on 0.0.0.0.
Server listening on 0.0.0.0 port 2222.
Generating 768 bit RSA key.
*STALL 0*
RSA key generation complete.
debug1: Server will not fork when running in debugging mode.
Connection from 10.0.0.67 port 34349
debug1: Client protocol version 2.0; client software version OpenSSH_3.6.1p2
debug1: match: OpenSSH_3.6.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_3.6
debug1: permanently_set_uid: 27/27
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
*SHORT STALL*
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
*STALL 1*
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
*STALL 2*
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user mihaak service ssh-connection method none
debug1: attempt 0 failures 0
Failed none for mihaak from 10.0.0.67 port 34349 ssh2
debug1: userauth-request for user mihaak service ssh-connection method
keyboard-interactive
debug1: attempt 1 failures 1
debug1: keyboard-interactive devs
debug1: auth2_challenge: user=mihaak devs=
debug1: kbdint_alloc: devices 'bsdauth'
debug1: auth2_challenge_start: trying authentication method 'bsdauth'
Failed none for mihaak from 10.0.0.67 port 34349 ssh2
Failed keyboard-interactive for mihaak from 10.0.0.67 port 34349 ssh2

****LOGIN****

debug1: userauth-request for user mihaak service ssh-connection method
password
debug1: attempt 2 failures 2
*STALL 3*
Accepted password for mihaak from 10.0.0.67 port 34351 ssh2
Accepted password for mihaak from 10.0.0.67 port 34351 ssh2
debug1: monitor_child_preauth: mihaak has been authenticated by privileged
process
debug1: Entering interactive session for SSH2.
debug1: fd 5 setting O_NONBLOCK
debug1: fd 9 setting O_NONBLOCK
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request pty-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_new: init
debug1: session_new: session 0
debug1: session_pty_req: session 0 alloc /dev/ttyp1
debug1: server_input_channel_req: channel 0 request shell reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: channel 0: rfd 11 isatty
debug1: fd 11 setting O_NONBLOCK
debug1: Setting controlling tty using TIOCSCTTY.


CLIENT SIDE (the stall numbers match those at the server side):

% ssh -p 2222 moebius
OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: Connecting to moebius [10.0.0.101] port 2222.
debug1: Connection established.
debug1: identity file /home/mihaak/.ssh/identity type -1
debug1: identity file /home/mihaak/.ssh/id_rsa type -1
debug1: identity file /home/mihaak/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.6
debug1: match: OpenSSH_3.6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
*SHORT STALL*
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
*STALL 1 + 2*
debug1: Host 'moebius' is known and matches the RSA host key.
debug1: Found key in /home/mihaak/.ssh/known_hosts:5
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/mihaak/.ssh/identity
debug1: Trying private key: /home/mihaak/.ssh/id_rsa
debug1: Trying private key: /home/mihaak/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Next authentication method: password

****LOGIN****

*STALL 3*
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: channel 0: request pty-req
debug1: channel 0: request shell
debug1: channel 0: open confirm rwindow 0 rmax 32768

*MOTD*

--
Martijn
http://www.sereneconcepts.nl

Dixitur illum subscription_remove_101@hot_remove_mail.com scribere...

>Hi,
>
>I have been pestered with this issue for quite some while (IIRC ever since
>using 2.7 or 2.9 or so). The problem is that connecting with ssh to my P120
>with 48MB of RAM takes up to about 30 seconds, but no shorter than 20
>seconds. Version 2.6 used to take no longer than about 5 or 10 seconds.

You might want to use SSH protocol version 1.

OTOH, my P-120 (with 128 MiB RAM tho doesn't seem to be _that_ slow
for ssh connections; I'm usually in in 10..15 secs.

//Thorsten
--
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r

Martijn wrote:

> shorter

Maybe you have any problem with routing table or gateway, and the ssh is too
late searching the host.

Regards
--
En realidad ese correo lo tengo como vertedero, no mandéis nada ahí. Al
menos que sea publicidad o reclamaciones de facturas sin pagar.

lococ

>> I have been pestered with this issue for quite some while (IIRC ever
>> since using 2.7 or 2.9 or so). The problem is that connecting with
>> ssh to my P120 with 48MB of RAM takes up to about 30 seconds, but no
>> shorter than 20 seconds. Version 2.6 used to take no longer than
>> about 5 or 10 seconds.
>
> You might want to use SSH protocol version 1.

Thanks for the tip. I had expected the protocol would be somewhat of an
issue. I guess I'll try a lower version next and else I will browse a
little through the sourcecode to see what happens around the aforementioned
messages.

--
Martijn
http://www.sereneconcepts.nl

Martijn wrote:
>>> The problem is that connecting with
>>> ssh to my P120 with 48MB of RAM takes up to about 30 seconds, but no
>>> shorter than 20 seconds.
>>
>> You might want to use SSH protocol version 1.
>
> I guess I'll try a lower version next ... [snipped]

That really speeds things up, but still slower than I had expected... But
acceptable none-the-less. Thanks again!

--
Martijn
http://www.sereneconcepts.nl

On Sun, 11 Apr 2004 23:55:24 +0200, Martijn wrote:

> That really speeds things up, but still slower than I had expected... But
> acceptable none-the-less. Thanks again!

Despite your assertion that reverse DNS works it does not. Place an entry
in moebius:/etc/hosts:

10.0.0.67 mihaak (or whatever that machine is named)