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: Conectivity problems affecting openssh ssh clients but not other ssh

Subject: Re: Conectivity problems affecting openssh ssh clients but not other ssh clients
Date: Sat, 21 Jul 2007 11:49:08 +1000
Tim Richardson wrote:
I want to ssh to a RedHat server running OpenSSH_3.9p1, OpenSSL 0.9.7a
Feb 19 2003
The server hosts several websites.

I have used three machines all from behind the same NAT
1) Debian unstable 4.6p1 OpenSSL 0.9.8e
2) Ubuntu 7.04: ssh -v = OpenSSH_4.3p2 Debian-8ubuntu1, OpenSSL 0.9.8c
05 Sep 2006
3) Mac OS X

The error log is below. The session hangs. Ctrl-C does not recover, I
have to kill the terminal window.

Note that a Windows machine running Putty succeeds, and on all
machines above, a Java ssh client succeeds.

The problem exists on two accounts on the server.
I can also duplicate the problem communicating the other way. That is,
on my home network I installed sshd on the Debian machine. Then using
the java ssh client, I shell in to the Red Hat remote machine. From
the shell, I use ssh to try to connect back to the Debian server at
home. The log is the same. Password authentication succeeds, but the
sessions hangs with the same final output from ssh -vvv

Meanwhile, I have a friend also using Debian who can shell into the
webserver machine.

So there is something about my network at home that kills multiple
versions of openssh but which does not affect other ssh clients. I
have a d-link router which acts as a firewall and NAT.

OpenSSH sets the IP TOS (to either "lowdelay" or "throughput") and some some routers have been known to choke on such packets.


[...]
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
that is the last message. The terminal hangs. ctrl-c can not interrupt.

The TOS is set immediately after the TCP_NODELAY so it's a pretty good bet that's your culprit.


As a workaround, you can recompile ssh then you can insert a "return;" at the start of packet_set_tos() in packet.c. Alternatively you can use ssh's ProxyCommand to use a program such as netcat as an alternative transport that doesn't set those bits, eg:

        ssh -o "ProxyCommand nc %h %p" yourserver

--
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>