17
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?

  • Do you have cron jobs running under root? – Shimon Rachlenko Mar 1 '13 at 18:44
5

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.

| improve this answer | |
  • Don't forget: sshguard – 0xC0000022L Mar 2 '13 at 2:47
  • 3
    They aren't trying passwords if they didn't get far enough to negotiate the crypto set. – Jo Rhett Apr 18 '17 at 16:21
  • 17
    This answer is completely wrong and a bit misleading. As mentioned below, if you get this message the connection didn't get to the stage of giving a username so it can't be attempting to guess one. It can be a) legitimately checking your machine is alive - which is fine or b) scanning for ssh ports that it would attack. However in case b) you would normally only see one single message from any given other address. You might end up with your machine rebooted by some person or system trying to fix things if the keepalive is done for monitoring. – Michael Sep 5 '17 at 15:16
34

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.

| improve this answer | |
  • 10
    Protocol-insensitive heartbeat checkers are annoying. – Falcon Momot May 7 '13 at 22:02
  • Yes -- for example, if your sshd server is running on an AWS EC2 instance and you have configured it behind an Elastic Load Balancer with a health check on the SSH port, you will see this message in the logs each time the health check runs. – Hugh W Feb 28 '18 at 11:32
10

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

| improve this answer | |
  • Can you explain what types of comm device might do this and why? – Elliott B Jun 19 '18 at 5:38
8

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.

| improve this answer | |
1

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.

| improve this answer | |
  • 1
    thanks, the spammed messages are gone(at least for now) and I don't have freepbx installed. – thkang Mar 1 '13 at 19:31
0

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.

| improve this answer | |
0

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.

| improve this answer | |
0

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.