I was reading the code from ndpi and found this line -

if (packet->payload_packet_len > 7 && packet->payload_packet_len < 100
    && memcmp(packet->payload, "SSH-", 4) == 0) {

I wanted to do the same thing using the gopacket library (packet sniffing library in golang) but the payload seems to be encrypted, which means it is not able to find "SSH-" string. Being a beginner in IS, I'm not sure what is happening -

applicationLayer := packet.ApplicationLayer()
if applicationLayer != nil {
    fmt.Println("Application layer/Payload found.")
    fmt.Printf("%s\n", applicationLayer.Payload())
    // Search for a string inside the payload
    if strings.Contains(string(applicationLayer.Payload()), "SSH-") {

         fmt.Println("SSH found!")
         fmt.Printf("%s\n", applicationLayer.Payload())

Output -

Application layer/Payload found.

Also I'm using a BPF filter with port set to 22, and I'm also sending traffic through my test server.

So my question is where I'm going wrong? My final aim is to detect some protocols independent of the port. How should I be approaching this problem?

  • What is "gopacket"? I can't find it in the repo. The obvious problem is that you are inspecting the flow while it is encrypted, while the ssh.c code is inspecting the flow after decryption.
    – schroeder
    Mar 10, 2017 at 12:01
  • I'm sorry for not stating, gopacket is a library for packet sniffing in golang.
    – hashcode55
    Mar 10, 2017 at 12:02
  • @schroeder The only time "SSH found!" is executed is when Diffie-Hellman key exchange occurs.
    – hashcode55
    Mar 10, 2017 at 12:05
  • 1
    @hashcode55: no I mean during protocol version exchange which comes before key exchange at the very beginning of the connection. Wireshark (and NIDS) simply treat the whole TCP connection as SSH since it starts with the typical SSH protocol version exchange and then contains the typical SSH packets. I recommend that you actually read the standard to understand how SSH looks on the wire. Mar 10, 2017 at 12:16
  • 1
    @hashcode55: yes, same problem with tls. Mar 10, 2017 at 12:28

1 Answer 1


The first packet from both client and server is the only payload that contains SSH-. Which is when both the client and the server are attempting to determine the cryptographic parameters.

If you want to parse SSH you'll need to fully understand the SSH protocol. Even after parsing the handshake you still won't be able to decrypt the application layer payloads. Unless you dump the keys in some way. I know PuTTY allows you to debug SSH sessions in that way. So it depends on what your goal is for sniffing.

Programs like Wireshark label protocols based off of port numbers. If you setup an SSH daemon on port 4444, and SSH to it; Wireshark will likely just say that it's TCP.

  • Oh I didn't know wireshark is port dependent. So the only time I'll be able to detect ssh will be during the key exchange right? My goal is to just detect the protocol.
    – hashcode55
    Mar 10, 2017 at 12:15
  • @hashcode55: wireshark can also treat port 4444 as SSH if you tell it do decode the traffic as SSH. But automatically it will only look for the application protocol commonly associated with the port. Mar 10, 2017 at 12:19
  • @hashcode55 Yes you'll need to observe the handshake in some form to determine the protocol. There are a couple of header values you could look for. The RFCs are probably the best place to look for that kindn of stuff.
    – RoraΖ
    Mar 10, 2017 at 15:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .