Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Secure-Shell
[Top] [All Lists]

Re: ssh communication issue

Subject: Re: ssh communication issue
Date: Wed, 11 Jan 2006 22:45:33 +1100
On Fri, Jan 06, 2006 at 05:05:29PM -0500, Larry Irwin wrote:
-Hopefully this is the right list-
Our ssh connections work fine on all our servers when we connect via 
the -local- network.
But, when we ssh from the -internet-, there are long pauses where i/o is 
not displayed/echoed to the screen on our Debian servers.
We experience 10 to 30 second pauses after a screen or 2 of display on 
Debian Etch kernel 2.6.12, SSH-2.0-OpenSSH_4.2p1 Debian-5.
We have same issue, with slightly shorter pauses, on a Debian Sarge kernel 
2.4.18, OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3.
We do not experience the problem on a SCO OS5 3.2v5.0.5 kernel, 
OpenSSH_2.2.0p1
Also, if we ssh to SCO first, then locally ssh to Debian, the pauses do not 
occur...
So it definitely has nothing to do with the network or infrastructure or 
the load on any server, etc.
It is something to do with either Debian or OpenSSH and only is triggered 
when the IP source IP is outside the LAN.
Does anyone know what might me contributing to the screen IO issue?

It's possibly an MTU issue which comes good when Path MTU Discovery
kicks in.  Read http://www.snailbook.com/faq/mtu-mismatch.auto.html and
try setting the MTU of the problem machine to 576 to see if the problem
goes away.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

<Prev in Thread] Current Thread [Next in Thread>