sshd log full of "Did not receive identification string from "

Question

Mar  2 02:34:02 freetalker3 sshd[28436]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:08 freetalker3 sshd[28439]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:13 freetalker3 sshd[28442]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:19 freetalker3 sshd[28445]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:24 freetalker3 sshd[28448]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:30 freetalker3 sshd[28451]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:35 freetalker3 sshd[28454]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:41 freetalker3 sshd[28457]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:46 freetalker3 sshd[28460]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:52 freetalker3 sshd[28463]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:57 freetalker3 sshd[28466]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:03 freetalker3 sshd[28469]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:08 freetalker3 sshd[28472]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:14 freetalker3 sshd[28475]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:20 freetalker3 sshd[28478]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:25 freetalker3 sshd[28481]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:31 freetalker3 sshd[28484]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:36 freetalker3 sshd[28488]: Did not receive identification string from 211.110.33.50

My /var/log/auth.log is full of these messages, spammed every 6 seconds. my server is on vps and the ip seems like it is an internal ip. what could be the cause of this issue?

Answer 1

Some miscreant (surprise!) is hammering at ssh to try to find a username/password combination that gets them into the system. Probably from some botnet doing the same to who knows how many other unsuspecting victims.

Install something like fail2ban or DenyHosts (some of both should be available for any Linux distribution), or set up your local firewall to limit SSH connection attempts. Changing the SSH port makes the dumb brute force tries fail, but it also makes legitimate uses fail.

Answer 2

Actually, this was from my hosting provider - they spam my VPS every 6 seconds, to show my server status on their web console. My server is displayed as active if my sshd answers them.

I just installed OpenVPN and allowed SSH only via that - so, according to my providers my server boasts 100% downtime.

Answer 3

This is most likely a keepalive (verifying the server is responding) from a comm. device.

Answer 4

Such messages are thrown by SSH when someone tried to access it but did not finish the steps. For example if NMS is checking whether port ssh 22 is up or not, it will simply try to connect on port 22 and if the connection is successful, it will hang up, in such cases SSH reports the same.

So it is because of an SSH port scan.

Answer 5

Try changing the ssh port from 22 to another one in sshd_config:

sudo nano /etc/ssh/sshd_config

If it doesn't stop messages, the issue can also be caused by this: Freebpx causes sshd errors in /var/log/secure log file or see discussion here "Did not receive identification string" in auth.log on Ubuntu forums.

Answer 6

It might also be an attempt to carry out a well known buffer overflow exploit.

It's documented in the filter /etc/fail2ban/filter.d/sshd-ddos.conf, which you can enable to protect yourself by these hack attempts:

Fail2Ban ssh filter for at attempted exploit
The regex here also relates to a exploit:
http://www.securityfocus.com/bid/17958/exploit
The example code here shows the pushing of the exploit straight after
reading the server version. This is where the client version string normally
pushed. As such the server will read this unparsible information as
"Did not receive identification string".

The target string for this exploit is (guess what?) "Did not receive identification string from ..."

You can distinguish legitimate connections coming from your provider network for monitoring purpose, by any other unauthorised sources, simply by checking the network range of the remote IP address.

It is possible to instruct fail2ban filter (through 'ignoreregex' directive) in order to ignore legitimate attempt accordingly.

Answer 7

In my case, this was caused by the Health Check for my Elastic Load Balancer (ELB). I, indeed, want the load balancer to ensure that sssd is running on my host, so this message was expected in my use case. For my specific use-case, using AWS FireLens, I was able to filter these messages out using the exclude-patterns property of the configuration object.

This issue was noted above in a comment, but I missed it the first few times I read this post, so I wanted to post it as a separate, top-level answer.

Answer 8

In my case those log entries were produced every 5 minutes because of a regular service scan by samhain - even though I was using some custom port (other than 22) for the SSH server. Disabling the detection of new services should prevent you from these annoying log entries (but may also weaken the protection by your IDS).

Answer 9

If your ever wondering who's port scanning or trying to authenticate on your machine just check:

# whois 211.110.33.50

# KOREAN(UTF8)

조회하신 IPv4주소는 한국인터넷진흥원으로부터 아래의 관리대행자에게 할당되었으며, 할당 정보는 다음과 같습니다.

[ 네트워크 할당 정보 ]
IPv4주소           : 211.110.0.0 - 211.110.239.255 (/17+/18+/19+/20)

etc.