openssh unix dev - Feb 2018 - User manipulation of tty mode opcodes / IUTF8 incompatibilities

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

On 12 February 2018 at 17:50, Nathan Anderson <nathan at anderson-net.com>
wrote:
> 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.
Sigh.  If you could provide the server's identity string (eg from "ssh
-v yourthing") we could add a bug bit to stop it from being sent.

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

On Sun, Feb 11, 2018 at 11:27 PM, Darren Tucker <dtucker at dtucker.net>
wrote:
> Sigh.  If you could provide the server's identity string (eg from
"ssh
> -v yourthing") we could add a bug bit to stop it from being sent.
$ ssh -v nathan at 10.0.0.1
OpenSSH_7.4p1, LibreSSL 2.5.0

[snip]

debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version ConfD-5.2.2.1
debug1: no match: ConfD-5.2.2.1

Thanks,

-- Nathan