4

I recently followed the advice at this blog to tighten down my SSH security, which included restricting key exchange algorithms to ones not vulnerable to known (or assumed known) capabilities of Prime attacks on DH.

I'm happy with the setup and it's working well, but since putting this in place on my server, I'm now seeing lots of messages like these in the logs:

sshd[19853]: fatal: Unable to negotiate with XXX: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]

This doesn't concern me, this is the usual random connections to port 22 I was seeing previously, except now they are being rejected at at key exchange instead of during user auth attempt (ie. trying to login as root, oracle, etc).

I am the only user on the host so all of these are probe/hack attempts. But it's interesting to me that the majority of attempted connections focus on these algorithms. Here's the breakdown of the most common signatures I see:

> journalctl -n 1000 | grep sshd | grep  "no matching key exchange" | sed -r 's/.*Their offer: (.*) \[preauth\]/\1/' | sort | uniq -c
      2 diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256
      4 diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
      1 diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
     63 diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
    411 diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

For the most common one diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1, I'm curious if this is a specific signature (ie. perhaps this is the default in certain older versions of SSH) or if this is an indication of hackers purposely restricting key exchange to focus on these weaker algorithms.

My google searching turns up nothing of value so I'm turning to this community in hopes of someone here having seen and researched this before. More curiosity than a problem to solve, but still hoping someone here has the knowledge to satisfy the curiosity. :)

Improve this question
3
  • My guess is that the attacker wants easy prey and is assuming that if you accept older key types, you're more likely to be easily compromised. If you reject them, you're both harder to 0wn and if an does attacker get in, you'll notice, flush them out, and possibly report or even retaliate.
    – Adam Katz
    Nov 24, 2015 at 23:03
  • Sorry I didn't make it clear, this is not a single attacker. I've already blocked China with ipset rules. The remaining regular hits (as shown above) are random IPs from throughout the world. I have sshguard setup, so each IP gets maybe a dozen or so attempts before it is permanently blocked. Which is what begs the question: if dozens, hundreds or thousands of attackers are focusing on the same algorithms, is there a known script kiddie or state-level vulnerability on these? Should they perhaps be dropped form ssh default settings?
    – Mark
    Nov 25, 2015 at 19:39
  • My (uninformed) vote is for a bot-net of some variety. What if that's 411 copies of the same virusware spread across the web randomly knocking on your door and doing ssh mining? Also, if I read the config right, isn't group14 2048 bits? Hardly a bad older key type; I don't think Logjam or Snowden indicated this group size was compromised (yet).
    – Andrew Philips
    Nov 26, 2015 at 21:26

1 Answer 1

Reset to default
1

I'm curious if this is a specific signature (ie. perhaps this is the default in certain older versions of SSH) or if this is an indication of hackers purposely restricting key exchange to focus on these weaker algorithms.

Your attackers are not interested in the key exchange algorithms at all, per se. It doesn’t matter if they are weak in this case or not. The key exchange allows the client to verify the server’s identity, and establishes cryptographic protection for the rest of the connection (the MAC and encryption keys). Your attacker is the client, and doesn’t care about any of that; all he wants to do is try a bunch of common username/password combinations to see if he can get in. Those key exchange algorithms are just common ones that, until recently, were almost always enabled; these in particular:

  • diffie-hellman-group1-sha1
  • diffie-hellman-group14-sha1

… are required to be implemented by RFC 4253.

Improve this answer

You must log in to answer this question.

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