SSH-1.99 sent by client not RFC compliant?

[Ben Armstrong]

We were bitten by the problem discussed here:

http://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=1437023

Thanks for the excellent analysis and workaround! It works! However, just as I was about to send a note back to the network staff where this problem was occurring to tell them that their firewall was exhibiting non-RFC-compliant behaviour, I checked the RFC Hoff cited myself:

http://www.faqs.org/rfcs/rfc4253.html

5.1. Old Client, New Server

Server implementations MAY support a configurable compatibility flag
that enables compatibility with old versions. When this flag is on,
the server SHOULD identify its 'protoversion' as "1.99". ...


Nowhere in the above excerpt nor anywhere else in the RFC do I see where it says the client should announce as "1.99" if it is capable of both v1 and v2. So isn't it the client that's not being RFC compliant?

Ben

[Hoff · Accepted solution]

Postel's rule applies here: "Be liberal in what you accept, and conservative in what you send."

Somebody might well choose to argue that a client sending 1.99 is a bug. Or might argue that version 1.99 from the client is a logical extension to the RFC, and for compatibility purposes with older servers. But nowhere in the RFC document do I see anything that specifically precludes an ssh client from sending that 1.99 value as the client version.

My own assumption would be that this behavior is compliant with the RFC (that's part of the "joy" of most anything that's left "unspecified" in an RFC), and that the use of 1.99 by the client is entirely intentional, and that the usage was to indicate the client could provide both versions 1 and 2 connections.

Beyond the lack of any specific "you can't do that" in the RFC (and parsing RFCs is such "fun"), this assumption is also based on the lack of a command-level knob to force the ssh client version within the OpenVMS ssh client (haven't checked 5.7 or the ssh update for 5.6), and also based on the generally crufty state of ssh support on OpenVMS. (And that the local V5.6-9ECO5 ssh client version mis-identifies itself as V5.5, after all.)

The usual approach for mandated requirements would be to disable V1 compatibility on one or both ends, and move on to more pressing matters. There's not a whole lot of reason to keep V1 around any more, after all.

If you're looking for an official statement from HP here in ITRC (and that's the only statement that really matters here, particularly if there are regulatory or audit or other concerns), then use the formal problem-reporting channels into the HP support center, and get the official answer to your question.

[Ben Armstrong]

It's not so much that the RFC says anything that prohibits the version string from being set to 1.99, but that it doesn't provide any interpretation that "this really means 2, but 1-capable" which is as you say a reasonable logical extension of the server-side version string rule, but without an actual clause in the RFC to back it up, leaves me with no ammo to fire back at the vendor of the firewall that filters us out to say "hey, guys, you're doing something unreasonable".

Now I'll have to see if we want to expend further energy, having solved the problem satisfactorily for this one case, trying to get HP to admit to a mistake here and possibly fix it. I have a feeling it's not going to be worth it. (Or on the flip side, complain to the vendor of the firewall product ... with a similar likelihood of not yielding satisfactory results.)

Sigh.

Ben

[Hoff]

No support, eh?

Time to start the work around adding that support, or loading an open-source or add-on ssh tool chain, or mayhap migrating to a platform where you can get that, then. Things are going to get dicy around here for sites lacking that if (when?) the patch lockdown arrives.

If the TCPIP$SSH_AIX_PATCH exec-mode system logical name from that other discussion didn't resolve this, then you're probably down-revision on your version or your patches, or there's a regression of some sort.

From TCP/IP Services V5.6 circa ECO3, and from V5.7...

30-Apr-2007 Alpha and IA64

Problem:

Connecting from an OpenVMS SSH client to AIX OpenSSH server
resulted in the following error message:

"Did not receive identification string from n.n.n.n"

Deliverables:

All SSH images

Reference:

TCPIP_BUGS Note 3576

Note:

The SSH client's modified behavior (sending an SSH protocol
version string of "SSH-2.0" rather than "SSH-1.99") applies
only when the new TCPIP$SSH_AIX_PATCH logical is defined in
the SYSTEM table with a non-zero value.

--

And FWIW, there should be nothing wrong with an sshd server getting that 1.99 version from a client. A 1.x sshd server should treat that as a 1.99 client, and either honor it or punt. A 2.x sshd server might choose to hand you 1 or 2 connection, depending on how it's coded. But it should work.

If the firewall vendor is Cisco, there are discussions around the 'net of how ssh 1.99 is handled. It was in use before the RFC got out, and this wouldn't be the first down-revision Cisco box in existence. (And there are probably also various other discussions of ssh and sshd "fun" for other vendors posted around the net, but you can run Google as well as I can.)

Regardless, call HP support if you have that access and get an official answer. I'm NOT that.

[Ben Armstrong]

Sure, I understand about needing to go to HP to get support, but since the workaround *did* work, (as I indicated in my original post,) I won't need to expend that effort. Not today, anyway. Besides, as you indicate, it could very well be the firewall that's at fault and in that case, HP couldn't do anything more for me.

In my response to the network support staff who look after the firewall, I have pointed at this discussion, so if they want to pursue how their firewall is dealing with 1.99 with Cisco (or whoever their vendor is) I'll leave that to them, now.

Thanks again,
Ben

[Hoff]

Everybody does look to be RFC compliant, BTW; IBM AIX, the particular firewall vendor here, and HP.

This is part of the "fun" of RFCs; they're not called standards for a reason; they're called requests for comments. The occasional truck-sized holes, err, omissions and ambiguities, and the requisite connect-a-thon events are a commonplace occurrence, too. And in some cases I'm well aware of, if you actually follow the applicable RFCs as they're written, your code will not interoperate. At all. NFS had a few of those, and particularly in the older revisions.

[Ben Armstrong]

Hah! Fun indeed. :)

[Jay So]

Hi,

Sorry I'm late to this party...

SSH that started shipping with TCPIP v5.4 (field tested with v5.3) never supported SSH protocol v1:

http://h71000.www7.hp.com/doc/732final/tcp_rn/tcp_rnpro_001.html#ssh2_problems

"The SSH1 protocol suite is not supported for terminal sessions, remote command execution, and file transfer operations. Parameters related to SSH1 in the server and client configuration files are ignored. "

And this is still true as of today (v5.7 ECO1) - we only support SSH protocol version 2 or SSH2.

As for RFC 4253,
"When this flag is on,
the server SHOULD identify its 'protoversion' as "1.99". Clients
using protocol 2.0 MUST be able to identify this as identical to
"2.0"."
One could argue that this should be both ways... And typically, I've seen it's a Firewall that's in between that's interfering when v1.99 is sent and firewall could be neither the server nor the client.

Neverthless, as mentioned prior, the AIX logical was created to avoid confusion and issues...

Jay So

[Ben Armstrong]

Sure, Jay. I'm satisfied that HP's is a valid interpretation of the standard, and that the flag provides an acceptable workaround. Thanks for your comment.