Mosh usually/always fails to get MOSH CONNECT when connecting to a server running Dropbear or tinysshd

When mosh is used to connect to a server running dropbear instead of OpenSSH's sshd, the client will rarely or never receive the MOSH CONNECT message. The ssh connection closes before any output is received from mosh-server. It appears that Dropbear doesn't tolerate the -n -tt flags very well (this is a somewhat nonsensical combination-- "don't open stdin" and "use a pty for interactive usage"). sshd seems to handle this fine.

@cjdelisle discovered this on a MIPS Creator C120 SBC running something called "Debian 8" with ab apt source of deb http://ftp.uk.debian.org/debian/ jessie-updates main, mosh/stable,now 1.2.4a-1+b2 mipsel installed, and a kernel bugfixed for a VM issue breaking mmap(), uname is Linux ci20-3006 3.18.3+ #4 SMP PREEMPT Sat Mar 7 10:25:33 EST 2015 mips GNU/Linux. But I've also reproduced this on an Ubuntu 16.10 x86_64 install.

Workarounds/fixes include deleting -n from the ssh command line generated by the mosh script, or deleting -tt from the same command line (only works with mosh-server 1.2.5+), or using a very current version of Mosh which has the --no-ssh-pty option.

Dropbear could do better in this area, but I'm not sure it's an actual bug, because of the oddness of the combination of options, and the way the ssh2 protocol does independent reliable unidirectional byte streams for stdin/stdout/stderr which can be opened/closed independently (actually, when -n is used, it doesn't create one for stdin at all, if I remember right).

We might be able to just drop the -n flag, I think this might be a remnant from when the script used a pty.

Start with the mosh script and inspect the SSH command it generates, focusing on the -n and -tt flags and the --no-ssh-pty behavior mentioned in the issue. Reproduce the connection against Dropbear or tinysshd, then verify that the client receives MOSH CONNECT while the existing OpenSSH behavior remains intact.