Read error; How to trace the error further?
mow...@googlemail.com
since some few weeks my ssh connections suddenly break. It occurs
randomly but never while typing. I feel it happens mostly while
executing some build commands or when leaving the prompt alone for
some time. The box is freebsd 6.0. I put on the maximum debugging mode
within my sshd_conf but still only get some very surficial output:
Jun 26 16:49:11 warbox sshd[46752]: debug1: do_cleanup
Jun 26 16:49:11 warbox sshd[46755]: Read error from remote host
87.36.218.85: Operation timed out
Jun 26 16:49:11 warbox sshd[46755]: debug1: do_cleanup
Jun 26 16:49:11 warbox sshd[46755]: debug1: PAM: cleanup
Jun 26 16:49:11 warbox sshd[46755]: debug3: PAM: sshpam_thread_cleanup
entering
Jun 26 16:49:11 warbox sshd[46752]: debug1: PAM: cleanup
Jun 26 16:49:11 warbox sshd[46752]: debug3: PAM: sshpam_thread_cleanup
entering
Jun 26 16:49:11 warbox sshd[46752]: debug1: session_pty_cleanup:
session 0 release /dev/ttyp1
Anyone a clue howto trace that nasty thing any further?
Moka
mikea
Hej!
It's time to tcpdump or wireshark one of those sessions, making sure to
grab the last several packets in the session. Look at the timestamps. It
may be helpful to print the dump with time deltas (-ttt for tcpdump),
rather than absolute times, so that long waits between packets will
stand out.
The tcpdump/wireshark output will show which end is dropping the
connection, and you may be able to see or infer the cause.
Do you have keepalive packets enabled (TCPKeepAlive in your
sshd_config)? This can be both a help and a hindrance. See `man
sshd_config` for more information; search on "[aA]live".
I hope this helps.
--
Mike Andrews, W5EGO
mi...@mikea.ath.cx
Tired old sysadmin
Todd H.
I've had network cards go bad, particularly those in/around spring
thunderstorms. They caused read errors.
Given that read errors I believe are on the link layer of things, it's
unlikely that sshd will be able to tell you much. I suspect you have
a network level issue that is only showing itself on long-standing ssh
connections. Dig into the error counters of the tcp ip stack perhaps
for more info. netstat -d and the like.
--
Todd H.
http://www.toddh.net/