About openssh verbose mode

[Markus Falb]

Hi,
I do not have a problem! Everything is working. But I do have a
question about how to interpret the debug output from openssh's ssh
client.

when doing a ssh -vv i get, for example

…snip
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,aes192-cbc,aes256-cbc,arcfour,rijnda...@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,aes192-cbc,aes256-cbc,arcfour,rijnda...@lysator.liu.se
snap…

these 2 lines look identical. But Is it really just the same
information duplicated?

…snip
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,uma...@openssh.com,hmac-
ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,uma...@openssh.com,hmac-
ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
snap…

again, why do I see 2 identical lines

…snip
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
snap…

what are these empty logentries for?

…snip
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
snap…

what does this mean?
--
Kind Regards, Markus

[Richard E. Silverman]

The problem here is that OpenSSH doesn't tell you what you're looking
at. These are the proposals from each side regarding various properties
of the connection: which key-exchange methods, encryption algorithms,
etc. to use. Several of these are set separately in each direction;
e.g., you can be using AES for encryption from client to server, but
3DES from server to client. The list is:

* key-exchange algorithms
* hostkey algorithms
* encryption algorithms (client -> server)
* encryption algorithms (server -> client)
* integrity algorithms (client -> server)
* integrity algorithms (server -> client)
* compression algorithms (client -> server)
* compression algorithms (server -> client)
* languages (client -> server)
* languages (server -> client)
* is this side sending an optimistic key-exchange packet? (boolean)

See RFC 4253 for details. Many of these client/server pairs are the
same, because OpenSSH has no reason to propose that they be
different. Finally, you see two entire sets of these because it shows
first the proposal the client sends, then the one it received from the
server (also not labeled).

> …snip
> debug2: kex_parse_kexinit:
> debug2: kex_parse_kexinit:
> snap…
>
> what are these empty logentries for?

That's the "languages" proposal; it's empty to indicate the peer has no
language preference.

> …snip
> debug2: kex_parse_kexinit: first_kex_follows 0
> debug2: kex_parse_kexinit: reserved 0
> snap…
>
> what does this mean?

If first_kex_follows were set (1), this would mean that this side is
following the proposal with an initial key-exchange packet of a type it
guesses is right for the peer, as an optimization.

"reserved" is the last field in the proposal, which is reserved for
future extensions to the protocol.

- Richard