Hi all,

I have had a shufty through the forums, but it doesn't appear that anyone else has had this problem? Am I unique??

When I launch putty from a Windoze PC to connect to a SUSE 9.2 PC, it immediately asks for:

login as:

I type root, and hit enter. There is then about a 27 second delay before it asks for the password. I then type the password and hit enter, and then it gives me the ~# prompt.

Anyone know why there is a 'long' delay before the password is asked for?

It's quite annoying when you have to login and out frequently for testing purposes.

Is it possibly something to do with PAM/SSH etc? I have a rudimentary knowledge of Linux, but cannot work out why this is happening.

Any help appreciated.

Many thanks,

Andy

When I launch putty from a Windoze PC to connect to a SUSE 9.2 PC, it immediately asks for:
login as:
I type root, and hit enter.
First of all you should not log in as root regardless of the network service you're accessing, please turn "PermitRootLogin" off in sshd_config, login as unprivileged user then use sudo to perform root account tasks.


There is then about a 27 second delay before it asks for the password.
I'd first check the system logs if there are any sshd/PAM entries you need to check, then sshd_config for VerifyReverseMapping set to "on", then check /etc/pam.d/system-auth for "nodelay" in the passwd pam_unix line. If that doesn't work, consider running sshd in triple debug mode on a different port and log the output.

ok, will change my login habits. thanks for the tip.

- where are the system logs (probably a dumb question, but i've never had to look at them before)
- in my sshd_config there is no line (or mention) of VerifyReverseMapping
- I don't have a /etc/pam.d/system-auth file

Am i missing something?

Check your sshd_config for the parameter GSSAPIAuthentication. Make sure it's set to "no". That's the default, but I found out recently that the Fedora Core 4 distribution of sshd_config has the parameter set to "yes" (though I realize your distro is Suse). Having it set to yes causes a DNS lookup in an attempt to resolve _kerberos.<FQDN>.

I found this by using ethereal to capture ethernet packets during the ssh login transaction. You might try doing the same to see if you can track down the source of the delay.

this happened to me whenever the kernel routing tables in the server were incorrect

I am encountering the same problem - when I log into the server using SSH, the password prompt appears. After I enter the password, I get a delay of about 12 sec before I get into the session.

What did you change wrt kernal routing tables? Which files did you alter?

I'm using Redhat Linux Enterprise: 2.4.21-4.EL

I've checked these:
/etc/ssh/sshd_config
#VerifyReverseMapping no
/etc/pam.d/system-auth
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok

But these settings are the same as my other server which I don't have problems with.