Take a look
In this instance, the client sent the Key Exchange Init packet first and the server sent it’s Key Exchange Init packet second. The client packet actually contained the list of encryption algorithms seen here, but it’s being printed out when I specify is_server == T, it should be printed when is_server == F, right?
It also looks like ssh_capabilities is only capturing details within the first Key Exchange Init packet, whether that be the one from the server or the client, and ignoring the second one.
So sometimes the server will send the KEI first, Bro captures that, then the client sends it’s KEI and it looks like Bro ignores it. Same thing happens when it’s the other way around. I want to be able to look at the details in both KEI’s.
Does this make sense? Does anyone know how this can be fixed or maybe I’m doing something wrong here?
First, here’s code that works: http://try.bro.org/#/trybro/saved/228261 (This is longer, because technically, clients and servers can specify different algs for each direction).
Here’s the relevant bit of Bro code: https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro#L225
c$ssh$capabilities is only designed for internal use. The comment for it says “Store capabilities from the first host for comparison with the second (internal use).” So, yeah. It’s basically exactly as you said. The data’s only stored there in order to find common algorithms once we see the other KEX packet. If you want to access the raw capabilities coming from the client or the server, you need to use the capabilities parameter in that event.
I feel like there’s a better way to document that that parameter is for internal use only, but I’m not sure what it is.
Does that help?
 - <https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro#L125>