2

I have a very interesting situation. I have a server running CentOS5.5, and whenever I try to ssh in using any external interface, there is a 4+ second delay, consistently. There is no such delay whenever I use the internal interfaces. For example, ssh'ing into mycomputer1 from mycomputer2 has little delay, but ssh'ing into mycomputer1.com from mycomputer2 goes to the external interface, where the lag occurs. /var/log/messages shows this when logging in with a password, with some redactions:

Mar 18 10:18:06 somecomputer sshd[788]: pam_unix(sshd:auth): authentication failure; 
Mar 18 10:18:06 somecomputer sshd[788]: pam_krb5[788]: TGT verified using key for ...
Mar 18 10:18:06 somecomputer sshd[788]: pam_krb5[788]: authentication succeeds for user
Mar 18 10:18:12 somecomputer sshd[788]: Accepted password for user from computer port myport ssh2
Mar 18 10:18:13 somecomputer sshd[788]: pam_unix(sshd:session): session opened for user myuser by (uid=0)

Here's /etc/pam.d/sshd:

auth       include      system-auth
account    required     pam_nologin.so
account    include      system-auth
password   include      system-auth
session    optional     pam_keyinit.so force revoke
session    include      system-auth
session    required     pam_loginuid.so
session    required     pam_limits.so

Here's system-auth:

auth        required      pam_env.so
auth        sufficient    pam_unix.so likeauth nullok
auth        sufficient    pam_krb5.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_succeed_if.so uid < 100 quiet
account     [default=bad success=ok user_unknown=ignore] pam_krb5.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so retry=3
password    sufficient    pam_krb5.so use_authtok
password    sufficient    pam_unix.so nullok use_authtok md5 shadow
password    required      pam_deny.so

session     required      pam_limits.so
session     required      pam_unix.so
session     required      pam_krb5.so use_first_pass
jyaworski
  • 33
  • 8

1 Answers1

1

It's a DNS issue, add UseDNS no into /etc/ssh/sshd_config, reload ssh and see if changes.

NickW
  • 10,183
  • 1
  • 18
  • 26
  • 1
    Thanks for the tip, but it appears to have done nothing at all. I too thought it was a DNS issue at first, but it appears to be something more sinister. Can you think of any other information I could provide to make it more clear? – jyaworski Mar 18 '13 at 15:05
  • Could there be any other component that uses DNS lookups? When you have a 4 to 5 second consistent pause, it's pretty much the standard DNS lookup timeout.. what if you add a line for computer in /etc/hosts? – NickW Mar 18 '13 at 15:09
  • To help determine if name resolution is a problem: when you ssh into mycomputer1.com, run `who --ips` to find the IP of mycomputer2 (or whatever it eventually got NATed to) and then run `getent hosts `. If there is a pause then name resolution is an issue. – Mark Wagner Mar 18 '13 at 16:56
  • Actually, it appears that there's some kind of DNS lookup somewhere in the process. If I add computer2.com into the hosts file for computer1 and then ssh to computer2.com from computer1, it goes instantly without a delay. Time to look into why this nameserver is so slow. I'll mark this as solved. Thanks for the assistance. It was most puzzling. – jyaworski Mar 18 '13 at 17:14
  • Yeah, it's one of the reasons I always run an internal DNS server, or at least a caching server, DNS has it's tentacles in lots of things you wouldn't expect :) – NickW Mar 18 '13 at 17:18