OpenSSH Hangs After Successful Authentication

[David A. Gershman]

So it may help others, I found a forum post 
<http://askubuntu.com/questions/344863/ssh-new-connection-begins-to-hang-not-reject-or-terminate-after-a-day-or-so-on> 
with the following note:

    /A problem can arise when you are trying to connect from behind a
    NAT router using OpenSSH. During session setup, after the password
    has been given, OpenSSH sets the TOS (type of service) field in the
    IP datagram. Some routers are known to choke on this. The effect is
    that your session hangs indefinitely after you gave your password./

As such, the post suggests using NetCat as a proxy:

    ssh -o "ProxyCommand nc %h %p" {user-name}@host.com


which worked for me.

I don't see this as a fix as, again, PuTTY and OpenSSH on the MacOS side 
of my laptop work fine as does OpenSSH with my TP-LINK USB device.

Good Luck!


On 01/08/2017 02:20 PM, Darren Tucker wrote:
> On Mon, Jan 9, 2017 at 8:54 AM, David A. Gershman
> <dagershman at dagertech.net> wrote:
>> Using my _internal_ WiFi card, OpenSSH succeeds to local (internal) LAN
>> hosts, but hangs after authentication to external LAN hosts; however
>> PuTTY works for all hosts.
> Two possibilities I can think of:
>
> 1) MTU black hole.  Check the "send-q" column on both client and
> server in netstat when it's in the hung state, compare MTUs between
> working and not working interfaces and try "ifconfig wlan0 mtu 576"
> before starting the ssh connection.
>
> 2) ssh(1) sets the IP type of service bits around the time of your
> observed hang.  In the past we have had reports of stateful devices
> not coping with the QoS of an established connection changing.  Try
> "ssh -o 'IPQos lowdelay lowdelay' yourserver".
>
> My bet is on #1, and my guess is the default MTU is different between
> your interfaces.
>