When your auth.log gets flooded with messages like:

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

This indicates your SSH server is receiving malformed connection attempts from 211.110.33.50 every 6 seconds. The client isn't completing the SSH protocol handshake by sending its identification string.

Common causes include:

• Botnet scanning activity (most likely scenario)
• Misconfigured monitoring system
• Buggy SSH client implementation
• Network middlebox interfering with connections

Block the offending IP using iptables:

sudo iptables -A INPUT -s 211.110.33.50 -j DROP

For persistent blocking, save the rules:

sudo iptables-save > /etc/iptables/rules.v4

1. Change SSH Port:

# Edit /etc/ssh/sshd_config
Port 2222

Then restart SSH:

sudo systemctl restart sshd

2. Implement Fail2Ban:

sudo apt install fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Configure in jail.local:

[sshd]
enabled = true
maxretry = 3
bantime = 1h

Use iptables to limit new connections:

sudo iptables -A INPUT -p tcp --dport 22 -m connlimit --connlimit-above 3 -j REJECT

Monitor auth.log after implementing changes:

tail -f /var/log/auth.log | grep sshd

You should see connection attempts dropping significantly.

---

When your auth.log gets flooded with messages like:

Mar  2 02:34:02 freetalker3 sshd[28436]: Did not receive identification string from 211.110.33.50

This indicates repeated connection attempts from the same IP (211.110.33.50 in this case) that fail at the very first step of SSH handshake. The client isn't even sending its SSH protocol version string.

1. Network Scanner Probing: Most common case - automated tools checking for open SSH ports. The 6-second interval suggests a deliberate scanning pattern.

2. Misconfigured Client: Less likely but possible - a broken SSH client implementation that can't complete the initial handshake.

3. Internal Network Issue: If this truly is an internal IP (though 211.* appears to be Korean ISP KT), check for network devices like load balancers or monitoring tools misconfigured to probe SSH.

Add this to your /etc/hosts.deny:

sshd: 211.110.33.50

Or use iptables:

iptables -A INPUT -s 211.110.33.50 -p tcp --dport 22 -j DROP

Consider these permanent solutions:

# Install fail2ban
sudo apt install fail2ban

# Configure custom filter (/etc/fail2ban/filter.d/sshd-noid.conf)
[Definition]
failregex = ^%(__prefix_line)sDid not receive identification string from <HOST>

Or modify sshd_config:

# /etc/ssh/sshd_config
MaxStartups 10:30:60
LoginGraceTime 30s

Create a monitoring script:

#!/bin/bash
# Count occurrences per IP
grep "Did not receive identification string" /var/log/auth.log \
  | awk '{print $NF}' | sort | uniq -c | sort -nr

For internal networks, check:

• Network monitoring tools (Nagios, Zabbix) with broken SSH checks
• Misconfigured jump hosts or bastion servers
• CI/CD pipelines with incorrect SSH configurations