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