You are not logged in.
How do I keep failed SSH logins from flooding dmesg and the system log? Besides switching to key logins, fail2ban or disabling SSH logging....
For example: [ 4164.178415] audit: type=1100 audit(1630246439.795:656): pid=1959 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=? acct="admin" exe="/usr/bin/sshd" hostname=31.184.198.71 addr=31.184.198.71 terminal=ssh res=failed'
I can't really wrap my mind around the audit thing. The audit daemon isn't running on boot (inactive, dead). I had to create /var/log/audit/audit.log and now succesful logins go there, after a reboot, but the failed ones not.
Perhaps I could disable the kernel parameter, but sysctl -a doesn't list audit as a paremeter ( https://wiki.archlinux.org/title/Audit_framework )
Auditctl -l says there are no active rules.
Offline
Offline
You should™ block off the offenders rather than silencing the attacks, but https://wiki.archlinux.org/title/Audit_ … d_messages
(… -F exe="/usr/bin/sshd" … should™ work)
Online
Well, the obvious first question: Do you need to have your system accesible from the Internet? The address indicates the attack you referenced did not come from your LAN.
If you have an open port at a well known address on the Internet, it will be probed. Continuously.
If you don't want to block, and it is only for your use, you might consider port knocking.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
2FA is also something you can consider if you really need password auth
Last edited by ugjka (2021-08-29 17:13:31)
https://ugjka.net
"It is easier to fool people, than to convince them that they've been fooled" ~ Dr. Andrea Love
Offline