2

Context: newly installed Debian 12, I get a bunch of strange logs related to ssh:

root@square:~# journalctl -u ssh -f
May 07 11:13:00 yop-square sshd[766]: error: kex_exchange_identification: Connection closed by remote host
May 07 11:13:00 yop-square sshd[766]: Connection closed by 10.91.66.91 port 53714
May 07 11:13:00 yop-square sshd[767]: error: kex_exchange_identification: Connection closed by remote host
May 07 11:13:00 yop-square sshd[767]: Connection closed by 10.106.14.62 port 54236
May 07 11:13:00 yop-square sshd[768]: error: kex_exchange_identification: Connection closed by remote host
May 07 11:13:00 yop-square sshd[768]: Connection closed by 10.35.165.19 port 60748
May 07 11:13:06 yop-square sshd[771]: error: kex_exchange_identification: Connection closed by remote host
May 07 11:13:06 yop-square sshd[771]: Connection closed by 10.35.165.49 port 42286
May 07 11:13:06 yop-square sshd[772]: error: kex_exchange_identification: Connection closed by remote host
May 07 11:13:06 yop-square sshd[772]: Connection closed by 10.80.98.247 port 47780

This could be appliances doing scans (part of a corporate network) but the behaviour/log is strange. I took a tcpdump and below is one of the exchanges leading to the logs above

No.     Time        Source          Destination     Protocol Length    Info
1380    122.725892  10.81.98.206    10.237.76.90    TCP 74  60422 → 22 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM TSval=4018386585 TSecr=0 WS=128
1381    122.725908  10.237.76.90    10.81.98.206    TCP 74  22 → 60422 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=660439285 TSecr=4018386585 WS=128
1382    122.726397  10.81.98.206    10.237.76.90    TCP 66  60422 → 22 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=4018386586 TSecr=660439285
1383    122.726505  10.81.98.206    10.237.76.90    TCP 66  60422 → 22 [FIN, ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=4018386586 TSecr=660439285
1384    122.730066  10.237.76.90    10.81.98.206    TCP 66  22 → 60422 [ACK] Seq=1 Ack=2 Win=65280 Len=0 TSval=660439290 TSecr=4018386586
1385    122.738228  10.237.76.90    10.81.98.206    SSH 106 Server: Protocol (SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2)
1386    122.738603  10.237.76.90    10.81.98.206    TCP 66  22 → 60422 [FIN, ACK] Seq=41 Ack=2 Win=65280 Len=0 TSval=660439298 TSecr=4018386586
1387    122.738792  10.81.98.206    10.237.76.90    TCP 60  60422 → 22 [RST] Seq=2 Win=0 Len=0
1388    122.739140  10.81.98.206    10.237.76.90    TCP 60  60422 → 22 [RST] Seq=2 Win=0 Len=0

In this scenario 10.237.76.90 is me (my Debian box) and 10.81.98.206 is them. Please note that all the activity is authorized and whatnot - the point of my question is to understand the exchange and find out who is misbehaving (or, alternatively, that everything is fine and the exchnage/logs are what they are supposed to be)

  • 1380 to 1382 → they initiate an SSH call and go though the handshake
  • 1383 → they send a FIN,ACK, why?. If they wanted to end the conversation, they should have sent a FIN and wait for a FIN,ACK, right?
  • 1384 → I send an ACK, not sure why.

Anyway, things seem to go south from there

  • 1385 → my ssh presents its protocol, no idea why since the connection is terminated
  • 1386 → me sends a FIN,ACK, out of the blue
  • 1387 and 1388 → they send two RST, probably to tell me to get lost

I am still not sure who is making a mess in the connection but I sure would like to know because it is either an issue with my sshd (which i seriously doubt), or the corporate scanning and so I will send a howler.

Improve this question
1
  • The first FIN-ACK at 1383 merely repeats the immediately prior ACK at 1382. Similarly the one at 1386 repeats the ACK at 1384. Same Ack= numbers in both cases. Not necessary: not incorrect.
    – user207421
    Commented May 7 at 22:58

1 Answer 1

Reset to default
4

I'm not 100% sure about this (in fact I'm only 65% sure about this), but:

1383 → they send a FIN,ACK, why?. If they wanted to end the conversation, they should have sent a FIN and wait for a FIN,ACK, right?

Not necessarily. TCP conversations are shut down independently in each direction, so these two are actually two independent things: you send FIN to end the conversation from your side and you send ACK to acknowledge any segments that you haven't acked yet. Those can be two separate packets or combined into one.

Likewise, although the server typically responds with a "FIN,ACK" in one packet, those are not inherently a single unit; the server may send its own FIN separately from ACK'ing the received FIN, if it wants. In this case, it still has some data that had already been queued for send before it can send the FIN.

1384 → I send an ACK, not sure why.

You have received a FIN, which has its own sequence number and warrants an ACK.

1385 → my ssh presents its protocol, no idea why since the connection is terminated

A FIN only means "this was the last packet from my side", but still allows data to be sent in the opposite direction. It can take time for the FIN to arrive and be processed, during which the software might have already submitted data to TCP, and that data should be properly delivered before full shutdown.

1387 and 1388 → they send two RST, probably to tell me to get lost

Not really sure why; maybe the client has already lost track of the connection prematurely (scanning tools such as nmap might be doing that), in which case a RST would be appropriate.

Improve this answer
8
  • You mention several times a FIN being sent, but I do not see one in the transaction. I do see FIN,ACK but not the FIN that should have initiated the termination.
    – WoJ
    Commented May 7 at 11:23
  • 1
    I think that is the FIN that initiated termination, isn't it? Like I said, it doesn't have to be a bare FIN. (It'll be a bare FIN when the connection is idle and everything so far has been ACK'd, but that isn't required to be the case; it can be combined with an ACK if one is pending.)
    – grawity_u1686
    Commented May 7 at 11:25
  • 1
    The RST is probably send because the client process has closed the connection before it has read the data from the server (the SSH banner). A close with data still in the receive buffer will cause a RST.
    – Steffen Ullrich
    Commented May 7 at 11:26
  • @u1686_grawity ah ok, you mean that the sequence FIN,ACK (them) and ACK (my reply) is correct. I dod not know, I thought that the sequence was FIN → FIN,ACK → ACK. TIL. In that case I still believe that something is not right because the connection is never closed cleanly (but I do not know whether the termination sequence is the culprit, or the fact that I send the protocol banner too soon)
    – WoJ
    Commented May 7 at 11:31
  • @WoJ: That's the "ideal" form of the sequence, but in reality it is just two independent sequences of FIN→ACK combined into one (first shutting down one direction, then the other), and the "FIN,ACK" in the middle of this sequence works the same way as the "FIN,ACK" that you saw in your capture: it's a FIN that ACK's the earlier segment (which only happens to also be a FIN).
    – grawity_u1686
    Commented May 7 at 11:34

You must log in to answer this question.

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