Internet Security Components - COM, ActiveX and .NET

Hi,

I have a question regarding SSHAuto mode in wodSSH. I have observed a strange behavior when the SSHAuto flag is used - it looks like WeOnlyDo will not connect to an SSHv1 machine using SSHAuto. Here are the details of my findings (server was running OpenSSH v3.4 with SSH protocol version = 1.5. You can see details on attached Wireshark screens)

when the SSHAuto flag is used, WOD sends 1.99 as SSH version (and a connection is dropped - "Protocol Major versions differ" - at least in our case). So it looks like WOD's SSHAuto mode is not so Auto and in practice only can connect to SSHv2 machines
when SSH1 flag (the flag is not used in IPAM) is used WOD sends 1.5 as supported version, and it is able to connect to a server running SSHv1
when SSH2 flag is used WOD sends 2.0 as supported version, and the connection is dropped:

My question is, what should be behavior or SSHAuto flag? How should it work? Should we be able to connect to an SSH v1 machine?

(used version: WeOnlyDo.Client.SSH.FIPS.dll 2.7.2.180)

Wojciech

locked

5494 views

Hi.

I just tried with latest wodSSH.NET and I was able to connect without any problems. Can you please update to the latest to confirm this is (not?) fixed in that version?

Regards,
Jasmine.

locked

5221 views

Hi.

I just tried with latest wodSSH.NET and I was able to connect without any problems. Can you please update to the latest to confirm this is (not?) fixed in that version?

Regards,
Jasmine.

The point that I would like to know what should happen - to rephrase, how the SSH protocol version negotiation part should look like.
For me, the fact that SSHAuto works only for SSHv2 is not a problem - but I would like to understand what was the idea behind SSHAuto and it should work (shouldn't it decide on a version based on the supported version reported by the server rather than just sending 1.99)?
Since in Our use of WoD, we are using the SSHAuto flag, and we would like to add a feature that would display the warning to the customer if he is using SSHv1. However, from the observed behavior looks like SSHv1 doesn't work in Auto mode and we can switch to use SSHv2 in code without breaking customers (since already they cannot connect to SSHv1 hosts - nobody has reported that, so they might not be even trying to connect to machines that are using SSHv1)

locked

5179 views

Hi.

SSH protocol specification defines that both sides, client and server, send blind exchange information to other side. For clients that support both SSH1 and SSH1, it sends SSH 1.99 - and that's what SSHAuto is doing.

So there's no logic we could add since we *MUST* send identification of your choice.

Jasmine.

locked

5235 views

Hi,

RFC 4253 specifies that an SSH server that supports both 2.0 and prior versions of SSH should identify its proto version as 1.99:

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". Clients
using protocol 2.0 MUST be able to identify this as identical to
"2.0". In this mode, the server SHOULD NOT send the Carriage Return
character (ASCII 13) after the identification string.

In the compatibility mode, the server SHOULD NOT send any further
data after sending its identification string until it has received an
identification string from the client. The server can then determine
whether the client is using an old protocol, and can revert to the
old protocol if required. In the compatibility mode, the server MUST
NOT send additional data before the identification string.

When compatibility with old clients is not needed, the server MAY
send its initial key exchange data immediately after the
identification string.

So, as you can see version "1.99" is for Server (not for client), so the correct behavour for the SSH server that is running oleder version (e.g. 1.5) is to drop connection when the client is sending 1.99. Efectively when client reports version as "1.99" it can connect only to a v2 servers

locked

5148 views

Hi.

There was discussion about this, and 1.99 from client side isn't specified in RFC. What if client supports only SSH2? What if client supports both SSH1 and SSH2? How is their identification same/different?

As RFC specifies, client that support SSH2 *MUST* send SSH-2.0. You should switch protocol property to SSH2 and you're all set, ignore our SSHAuto in that case. It's up to you.

Anyway, if you have problem with SSHAuto, why don't you switch to specific SSH1 or SSH2 Protocol property setting and get rid of this "bug" that's been here for 20 years and worked correctly, so I'm not sure we'll change it at this time.

Jasmine.

locked

5159 views

Product groups

Support

SSHAuto (wodSSH / wodSSH.NET)

SSHAuto

SSHAuto

SSHAuto

SSHAuto

SSHAuto

About

Contact