User manipulation of tty mode opcodes / IUTF8 incompatibilities

Nathan Anderson nathan at anderson-net.com
Mon Feb 12 17:50:17 AEDT 2018


Hey all,

The IUTF8 tty mode support added to the client in 7.3 unfortunately
appears to have broken interop with a handful of noncompliant server
implementations that immediately close the connection when they are
sent an opcode that they know nothing about, rather than ignore it.
Setting the value to 0 is not enough: its mere presence regardless of
value is enough to cause the server to bomb out.

In my specific case, I can no longer connect to the SSH server built
into a particular piece of core network equipment; the implementation
is by Tail-f/Cisco (ConfD) and for all I know might be fixed in a
newer release of that product, but as we're dealing with a
vendor-of-a-vendor thing, who knows how long the fix will take to
trickle down to a firmware update, assuming that a fix on the server
side even exists yet.

I can no longer connect to this equipment via the OpenSSH client
binary included with any shipping version of macOS released for the
past year+.  Which sucks.  I'm sure recent versions of other
widely-deployed platforms that OpenSSH ships with are similarly
affected.  Interestingly, the Windows builds done by MLS Software
(https://www.mls-software.com/opensshd.html) work up until their
release of OpenSSH 7.5, so apparently their 7.3 and 7.4 were built
without IUTF8 #DEFINEd.  Luckily for me, latest Ubuntu LTS (Xenial)
still ships with 7.2, but I'm running on borrowed time here.

Clearly the fault here lies with the server implementation, but it is
still somewhat surprising to me that there is seemingly no way to
override this new behavior on the client side without rebuilding from
source...I would have thought the existence of badly-behaving servers
in the wild would have been assumed.  I have looked high and low (man
pages, long Google sessions, even a quick browse through the source)
for a way to ask the client to completely omit a specific opcode
value, but if it exists then I am blind.  (And if it exists and I'm a
dumbass, I apologize profusely in advance for wasting everybody's
time.)

I *can* successfully connect to this server using 7.3+ with -T, but
that's a "blunt object" fix, plus then I don't have a truly
interactive session.

PuTTY users apparently ran into a similar problem when it implemented
this TTY mode in 0.68; see
https://groups.google.com/d/msg/comp.security.ssh/om6bu1WCQPE/V7UCgPMnFQAJ
-- this got fixed in 0.69 (as documented later in the thread), and the
ability in that client to selectively and manually override any TTY
mode opcode value is *very* nice.

What are the chances that OpenSSH devs would consider either 1)
implementing such a feature, 2) accepting a patch from an outside
contributor for such a feature, and/or 3) cobbling together (for now,
at least) a quick patch that implements a switch to prevent *just* the
IUTF8 opcode from being transmitted?

Thanks,

-- 
Nathan Anderson



More information about the openssh-unix-dev mailing list