A case where you are wrong:
In reponse to SSH_MSG_KEX_DH_GEX_REQUEST, you dissect the reply as
SSH_MSG_KEXDH_REPLY
(http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-15.txt,
page 22), while it's actually SSH_MSG_KEX_DH_GEX_GROUP
(http://www.openssh.org/txt/draft-ietf-secsh-dh-group-exchange-02.txt,
page 4).
This is evident in regular OpenSSH to OpenSSH connection (6th packet,
3rd reply from server to client, after Protocol and key exchange packets).
I always though this redefinition is a bad idea, but hey, that's the
protocol...
Huagang XIE wrote:
Yaniv Kaul wrote:
Hi all,
I'm glad someone was finally less lazy than I and came with a
dissector to SSH. ;-)
However, what I found confusing, is that it seems that some values
could have differernt meanings.
From
http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-15.txt,
page 22:
/* Numbers 30-49 used for kex packets.
Different kex methods may reuse message numbers in
this range. */
#define SSH_MSG_KEXDH_INIT 30
#define SSH_MSG_KEXDH_REPLY 31
How did you solve this? Indeed, in some other drafts, those numbers
are re-used!
For example, from
http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-05.txt,
page 15:
. Summary of Message Numbers
Yes, you are right.
I take the simply solution, I just take that value from ssh2.h and use
it. Althought It maybe wrong, but I am sure after
some times, with the effort of the community, it will be get solved
some times later..:-)
-huagang
The following message numbers have been defined for use with
GSSAPI-based key exchange methods:
#define SSH_MSG_KEXGSS_INIT 30
#define SSH_MSG_KEXGSS_CONTINUE 31
#define SSH_MSG_KEXGSS_COMPLETE 32
#define SSH_MSG_KEXGSS_HOSTKEY 33
#define SSH_MSG_KEXGSS_ERROR 34
The numbers 30-49 are specific to key exchange and may be redefined
by other kex methods.
Huagang XIE wrote:
Here it is, Now the SSHv2 and SSHv1 is a flag in the flow data
structure now.
huagang