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@xxxxxxxxxxxxx> 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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
