UNIX for Dummies Questions & Answers

Anyway, if you wish to eliminate a possible "network delay"; simply login to the server and ssh -vvv back to the same server (you are on) and that should eliminate any networking issues from the situation.

After all, if you are on "Server A" and ssh -vvv to "Server A", and there is still a delay, the problem is obviously and clearly the problem specified in the log file.

@fpmurphy + @neo.........Aren't we all saying that there appears to be a DNS problem which stops everything connecting, and there is plainly also a ssh issue. I would recommend that the DNS is fixed first so that all connections work except ssh. Then hopefully though, the ssh will fail with a shorter delay than 5 minutes. The ssh gets fixed after that.

Telnet should just work whether ssh is screwed up or not.

The fact that the server might be able to connect to itself (find itself) doesn't mean that other clients can find the server (in less than 5 minutes).
The server might resolve its own address instantly but clients using whatever DNS they are configured to use may not.

Anybody disagree with that? Or am I reading this wrong?

No.

I've seen no proof that this is a (or there is a) DNS issue. There may or may not be a DNS issue, that has yet to be proven.

That is only conjecture (a guess), made without proof.

The only thing we have which is a fact, that I have seen so far, are the errors in the log file.

If you have a working theory that there is a DNS error, please provide a way for the poster to confirm this; as "guessing" and "accepting" is simply not an effective troubleshooting methodology.

Let's not debate guesses and conjecture. Thanks!

This is a weird one and I suspect that not everything was reported with 100% accuracy. My guess would be an NFS problem on the destination system. If this is correct, then a "df -k" on the destination system will also hang for a long while.

He should also be able to look at the NFS logfile (syslogd) for clues if your "df -k" test on the destination filesystem shows it is causing part of the problem.

Again, when we read the ssh -vvv output in the well written post above, it seems quite obvious the process is hanging trying to read a good key file, over and over. again. There are myriad entries of this key read failure.

Frankly, I'm not sure (of the logic of) why a set of ssh keys for a server would be remotely hosted on another server. If sshd was configured to be dependent on a remote server, then any network problem could cause sshd problems and, in turn, problems logging in to debug; which is the last thing a system admin would desire.

Well, for better or worse my ssh keys are in my home directory. My home directory physically resides on a Netapp and it is remote mounted to several hundred systems. You're right, it's a drag when the Netapp is having a bad day.

But that's not what prompts my guess. Trouble with ssh keys won't slow down telnet. DNS or networking issues won't slow down only telnet/ssh but leave ftp running ok. So I figure that something else is afoot.

A Solaris system with slow telnet and ssh but fast ftp... I see that all the time. Almost always the Solaris box is stuck checking quotas on some obscure file system that is NFS mounted but has a stale file handle. But my guess does have trouble too. Quotas are checked after the user is authenticated but before a shell prompt appears. Still a quick "df -k" on the destination system would be the first thing I would check.

quota check and mail check are in /etc/profile and /etc/.login. Can be commented out.
A user can skip the tests by having .hushlogin in her home directory.
This is at login.
A fast test is to run a remote shell command only, for example

Code:

ssh host uname

(Not possible with telnet.)

---------- Post updated at 03:35 AM ---------- Previous update was at 03:20 AM ----------

Also authentication (e.g. Kerberos PAM cannot reach Kserver) can be the problem.
A systematic debugging is

Code:

truss -afp pid_of_master_sshd

When there is the unwanted pause, stop the truss with Ctrl-C and look at the last output.