Someone is trying to brute-force the password for your
(It doesn't matter if password login is prohibited for it — they can still try, they'll just fail every time.)
You normally won't want to suppress these log messages; they can be useful information when someone does manage to break into your system at some point.
(Though you'll need append-only off-site backups of the log to be safe in that case.)
You can use a log aggregation system (like Logstash or Graylog) to filter off these messages into a different view to deal with them separately, or you can
grep -v '[Aa]uthentication failure]' /var/log/syslog | less to filter them out when manually viewing the log.
You can also report the brute-force attempts to the operator of the source system, but that's usually tilting at windmills.
(Note that you're seeing the private network address of your NAT gateway (172.16.2.1), so you'll need to check the gateway for the actual external address.)
The usual mitigations are just pre-filtering and obfuscation:
Make sure password-based login for the
root user is disabled in your
# or (at the very end of the file, since `Match` extends until the next `Match` or end of file)
Match User root
- Configure your firewall to block connections to the SSH port from IP ranges that you don't normally connect from (either as a whitelist or a blacklist),
- Possibly change the SSH port to a non-standard one (though that can cause compatibility issues with software that doesn't support custom ports).