1

I am getting the following error messages in my Linux machine.

sshd[9287]: message repeated 2 times: [ error: PAM: Authentication failure for root from 172.16.2.1]  
sshd[9287]: Received disconnect from 172.16.2.1: 11:  [preauth]  
sshd[9312]: error: PAM: Authentication failure for root from 172.16.2.1  
sshd[9315]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.16.2.1  user=root  

this happens often and my log is full of this error message. How to overcome this issue?

2
  • What have you tried so far? Where do you stuck? Nov 23 '18 at 7:22
  • So far changed sshd_config file, no positive results
    – jerry
    Nov 23 '18 at 9:06
3

Someone is trying to brute-force the password for your root user.
(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 /etc/ssh/sshd_config:

    PermitRootLogin without-password
    
    # or
    PermitRootLogin no
    
    # or (at the very end of the file, since `Match` extends until the next `Match` or end of file)
    Match User root
    PasswordAuthentication no
    
  • 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).
3
  • 1
    Hello @n.st I'm in a reverse situation at present, from my static IP these attacks are being made to some other webserver (they have notified me about it). What can I do to find where is the problem in my servers? Looks like someone has breached into my servers and doing the attacks. The last possible solution I can think of is to re-install all of my On-Prem servers and start from scratch. I'm using Ubuntu 18 in all of them. May 28 '20 at 5:28
  • @SunilKumar Your server has been hacked. Solution: 1. cat /var/log/auth.log | grep -i "accept". Also check auth.log.1, etc. You will see what users have been connected. Find the suspicious one. In my case it was vsftp (password was brute-forced). 2. Find all processes of this user: pa -u vsftp. 3. Kill them: sudo kill -9 processIdHere. 4. Del user folder: sudo deluser --remove-home vsftp. 5. Change ssh port. 6 Disable password ssh authentication. Jun 30 '20 at 12:50
  • Hello @TitanFighter thanks for your suggestion, I have noted down all the steps for reference in future. Since, this was one month back and didn't found a way to fix it, I have re-installed OS from scratch in all servers and yes I have disabled password authentication after installation, only ssh is allowed from a different port. Thanks again. Jul 1 '20 at 5:27

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