Ross Crawford wrote:
> Hi,
>
> Yes, I'm a bit of a n00b with SSH, but I managed to get PuTTY working
> with OpenSSH on my debian box. The problem I have is that after I type
> the login name, it takes 10-15 seconds to authenticate. How do I find
> out why it's so slow?
>
> Thanks for any info.

Found the problem - my IPs are assigned from my DSL router via DHCP, and
it doesn't create any dynamic host entry for the client, so the reverse
DNS lookup was timing out. So I added "UseDNS no" to sshd-config, and no
more waiting!

ROSCO

Ross Crawford wrote:
> Ross Crawford wrote:
> .... so the reverse
> DNS lookup was timing out. So I added "UseDNS no" to sshd-config, and no
> more waiting!
>

it will also try both protocols(1,2) and the RSA/DSA and host
authentications, so config the target host to use specifically that
technique you used to create your pass-phrase and it will carve of some
more time.

--
---
Jeff B (remove the No-Spam to reply)

Jeff B writes:
>it will also try both protocols(1,2) and the RSA/DSA and host
>authentications, so config the target host to use specifically that
>technique you used to create your pass-phrase and it will carve of some
>more time.

I very much doubt any of those things will make any noticeable
difference, since in all those cases, a single algorithm is chosen and
the CPU-intensive cryptography (etc) is only performed for the chosen
algorithm. The time taken to make the decision should be negligible, so
eliminating the choice of algorithms should make no difference.

Jacob Nevins wrote:
> Jeff B writes:
>
>>it will also try both protocols(1,2) and the RSA/DSA and host
>>authentications, so config the target host to use specifically that
>>technique you used to create your pass-phrase and it will carve of some
>>more time.
>
>
> I very much doubt any of those things will make any noticeable
> difference, since in all those cases, a single algorithm is chosen and
> the CPU-intensive cryptography (etc) is only performed for the chosen
> algorithm. The time taken to make the decision should be negligible, so
> eliminating the choice of algorithms should make no difference.

however, the try, fail, new choice and round trip times all add up :-)

--
---
Jeff B (remove the No-Spam to reply)

>>>>> "JB" == Jeff B writes:

JB> Ross Crawford wrote:
>> Ross Crawford wrote: .... so the reverse DNS lookup was timing
>> out. So I added "UseDNS no" to sshd-config, and no more waiting!
>>

JB> it will also try both protocols(1,2) and the RSA/DSA and host
JB> authentications

I'm sorry, but none of this makes any sense. Neither the choice of SSH
protocol version nor the server key type can be "re-tried" in the course
of a single SSH connection; if either one doesn't work out for whatever
reason (e.g. the client has two keys for a host, and the one chosen
doesn't verify), the connection must be aborted. The only way what you're
describing could happen is if the client software made multiple SSH
connections in order to try these different parameters -- and PuTTY
doesn't appear to do that; I just tried it.

JB> so config the target host to use specifically that technique you
JB> used to create your pass-phrase and it will carve of some more
JB> time.

Passphrases have to do with user keys, which affect user authentication.
Above you mentioned issues with server authentication and protocol
version. Even if the issues you mentioned were valid, how could this
affect them in any way?

--
Richard Silverman
res@qoxp.net