I read it, but the issue here is not related to wrong password typing. Then, the issue persists with ssh, so this article is definitely not related to the issue we encounter.
I mean, i do not want to disable the lockout mechanism or only as a last resort
Unless you’re using passwordless-login mechanisms faillock certainly blocks logins via ssh if triggered.
That conclusion is premature. You can test by (temporarily) disabling faillock and trying to provoke the issue.
I will do that too, indeed
@freggel.doe I achieved to provoke the issue. By running 3 times Mugshot (in xfce), only run the app, do nothing and close it. I always get auth failed in journalctl.
pam_unix(sudo:auth): auth could not identify password for [barracuda]
pam_unix(sudo:auth): conversation failed
Then my sudo password is locked. My root and user password are different.
Then, i did the same tests with Endeavous OS, exactly same results.
I also put deny = 0 in faillock.conf. In that case, my user account is never locked.
It’s maybe premature to conclude Mugshot is the root cause. It causes my user to be locked, for sure, but it’s maybe not the root cause.
This also happens on Cinnamon with Lightdm…but I have noticed that it is usually when updates are performed but the computer is not restarted, then the screen locks and for some reason it will not unlock. I have made it a point to always restart after any large update… have not had the issue since.
Faillock looks very promising. Its config file by default is /etc/security/faillock.conf and the logs for fail lock are at /var/run/faillock. You can look at the records with sudo faillock --user USERNAME. My normal account has no records but my root has tons:
root:
When Type Source Valid
2021-04-01 21:59:59 RHOST 112.85.42.17 V
2021-04-01 21:44:54 RHOST 112.85.42.17 I
2021-04-01 21:44:58 RHOST 112.85.42.17 I
2021-04-01 21:45:00 RHOST 112.85.42.17 I
2021-04-01 21:46:40 RHOST 112.85.42.17 I
2021-04-01 21:46:43 RHOST 112.85.42.17 I
2021-04-01 21:47:29 RHOST 112.85.42.17 I
2021-04-01 21:51:05 RHOST 112.85.42.17 V
2021-04-01 21:51:56 RHOST 112.85.42.17 V
2021-04-01 21:52:02 RHOST 112.85.42.17 V
2021-04-01 21:56:27 RHOST 112.85.42.17 V
2021-04-01 21:57:18 RHOST 112.85.42.17 V
2021-04-01 21:57:22 RHOST 112.85.42.17 V
2021-04-01 21:58:06 RHOST 112.85.42.17 V
2021-04-01 21:58:13 RHOST 112.85.42.17 V
2021-04-01 21:59:00 RHOST 112.85.42.17 V
2021-04-01 21:59:04 RHOST 112.85.42.17 V
2021-04-01 21:59:07 RHOST 112.85.42.17 V
2021-04-01 21:59:52 RHOST 112.85.42.17 V
2021-04-01 22:00:45 RHOST 112.85.42.17 V
2021-04-01 22:00:48 RHOST 112.85.42.17 V
2021-04-01 22:00:52 RHOST 112.85.42.17 V
2021-04-01 22:01:36 RHOST 112.85.42.17 V
2021-04-01 22:01:40 RHOST 112.85.42.17 V
2021-04-01 22:01:43 RHOST 112.85.42.17 V
2021-04-01 22:02:30 RHOST 112.85.42.17 V
2021-04-01 22:02:34 RHOST 112.85.42.17 V
2021-04-01 22:02:38 RHOST 112.85.42.17 V
2021-04-01 21:41:26 RHOST 112.85.42.17 I
2021-04-01 21:42:14 RHOST 112.85.42.17 I
2021-04-01 21:42:17 RHOST 112.85.42.17 I
2021-04-01 21:42:21 RHOST 112.85.42.17 I
2021-04-01 21:43:07 RHOST 112.85.42.17 I
2021-04-01 21:43:11 RHOST 112.85.42.17 I
2021-04-01 21:44:06 RHOST 112.85.42.17 I
2021-04-01 21:44:09 RHOST 112.85.42.17 I
2021-04-01 21:44:13 RHOST 112.85.42.17 I
2021-04-01 22:03:24 RHOST 112.85.42.17 V
2021-04-01 22:03:27 RHOST 112.85.42.17 V
2021-04-01 22:03:31 RHOST 112.85.42.17 V
2021-04-01 21:37:50 RHOST 112.85.42.17 I
2021-04-01 21:37:54 RHOST 112.85.42.17 I
2021-04-01 21:37:58 RHOST 112.85.42.17 I
2021-04-01 21:38:43 RHOST 112.85.42.17 I
2021-04-01 21:38:46 RHOST 112.85.42.17 I
2021-04-01 21:38:50 RHOST 112.85.42.17 I
2021-04-01 21:39:40 RHOST 112.85.42.17 I
2021-04-01 21:39:44 RHOST 112.85.42.17 I
2021-04-01 21:39:47 RHOST 112.85.42.17 I
2021-04-01 21:40:32 RHOST 112.85.42.17 I
2021-04-01 21:40:36 RHOST 112.85.42.17 I
2021-04-01 21:40:38 RHOST 112.85.42.17 I
2021-04-01 21:41:20 RHOST 112.85.42.17 I
2021-04-01 21:41:24 RHOST 112.85.42.17 I
2021-04-01 21:43:14 RHOST 112.85.42.17 I
2021-04-01 21:45:46 RHOST 112.85.42.17 I
2021-04-01 21:45:50 RHOST 112.85.42.17 I
2021-04-01 21:45:53 RHOST 112.85.42.17 I
2021-04-01 21:46:47 RHOST 112.85.42.17 I
2021-04-01 21:47:32 RHOST 112.85.42.17 I
2021-04-01 21:47:36 RHOST 112.85.42.17 I
2021-04-01 21:48:24 RHOST 112.85.42.17 I
2021-04-01 21:48:26 RHOST 112.85.42.17 I
2021-04-01 21:48:29 RHOST 112.85.42.17 I
2021-04-01 21:49:18 RHOST 112.85.42.17 V
2021-04-01 21:49:22 RHOST 112.85.42.17 V
2021-04-01 21:49:25 RHOST 112.85.42.17 V
2021-04-01 21:50:10 RHOST 112.85.42.17 V
2021-04-01 21:50:14 RHOST 112.85.42.17 V
2021-04-01 21:50:17 RHOST 112.85.42.17 V
2021-04-01 21:51:03 RHOST 112.85.42.17 V
2021-04-01 21:51:09 RHOST 112.85.42.17 V
2021-04-01 21:51:58 RHOST 112.85.42.17 V
2021-04-01 21:52:49 RHOST 112.85.42.17 V
2021-04-01 21:52:52 RHOST 112.85.42.17 V
2021-04-01 21:52:56 RHOST 112.85.42.17 V
2021-04-01 21:53:41 RHOST 112.85.42.17 V
2021-04-01 21:53:45 RHOST 112.85.42.17 V
2021-04-01 21:53:48 RHOST 112.85.42.17 V
2021-04-01 21:54:36 RHOST 112.85.42.17 V
2021-04-01 21:54:39 RHOST 112.85.42.17 V
2021-04-01 21:54:43 RHOST 112.85.42.17 V
2021-04-01 21:55:28 RHOST 112.85.42.17 V
2021-04-01 21:55:32 RHOST 112.85.42.17 V
2021-04-01 21:55:34 RHOST 112.85.42.17 V
2021-04-01 21:56:20 RHOST 112.85.42.17 V
2021-04-01 21:56:23 RHOST 112.85.42.17 V
2021-04-01 21:57:25 RHOST 112.85.42.17 V
2021-04-01 21:58:09 RHOST 112.85.42.17 V
2021-04-01 21:59:55 RHOST 112.85.42.17 V
Anyone know what I am looking at here? Why would there be so many rapid authentication requests?
Please verify if a user named barracuda exist in /etc/passwd
Could be anything
- Do you recognize the IP?
- Do you have multiple public keys in your local .ssh folder?
There is an issue with ssh - I don’t know if it is bug or just configuration.
But not so long ago I had an issue where I - when logging onto ssh with user:pass - was rejected with message too many failed logins - even though I only tried once. Suffice to say I was very frustrated for some hours until I located the issue.
I cannot even remember the search result where I found the hint but it was caused by having several key-pairs in your .ssh folder - then all those would be tested before I even got to the prompt.
In this particular situation - I modified my local user .ssh/config to include - as the first entry
Host *
IdentityAgent none
This will not block use a key file - it will only ensure that you do not spam the remote ssh service asking for public keys.
Yes, my user exists, this is my main user (uid 1000). Nevertheless, at least, now, i can say there is an issue with Mugshot. Once you click on it, it causes an auth error
pam_unix(sudo:auth): auth could not identify password for [barracuda]
pam_unix(sudo:auth): conversation failed
I tried in Endeavous OS and Xubuntu with Boxes, same results.
And for the other cases when a lockout happened to me, it’s possible i typed a wrong password 3 times in 15 minutes (the default fail_interval). I realized that by looking how pam_faillock.so works.
You do not necessary need to type the wrong password 3 times in a row to cause a lockout, but also if you do it during the default 15 minutes interval, i did not know that.
Right now my ~/.ssh contains only id_ras and id_rsa.pub.
I do not recognize the IP Address
It looks like I actually have several ssh keys in my /etc/ssh/ directory.
ls /etc/ssh/ gives
moduli ssh_host_dsa_key.pub ssh_host_ed25519_key.pub
ssh_config ssh_host_ecdsa_key ssh_host_rsa_key
sshd_config ssh_host_ecdsa_key.pub ssh_host_rsa_key.pub
ssh_host_dsa_key ssh_host_ed25519_key
I will admit I am brand new to ssh. I got it merely working so I could manage my computer remotely but I am not sure if I am doing it right or not. I plan to dive in and learn it better soon.
If you don’t recognize the IP address - I am guessing - your ssh runs on default port 22 and you have allowed incoming traffic in firewall/router?
If so - I recommend to close it - and if you need external access then you should open a non default port e.g. 63000 and map the port to your internal port 22 on the target system.
Interesting. So you think this may be an external attack?
No - that is not what I am saying - because I don’t know how you have configured your network.
I am merely guessing and based on my guessing I come up with suggestions which may guide you in the right direction.
One suggestion is to look into your configurations to avoid potential scanning from outside and to avoid potential issues caused by scanning from outside your network.
All those messages are a clear sign of a bruteforce password attack on your root account - and depending on the complexity of your password it could be a matter of time before they guess it - and then your system are owned and not by you.
Protecting against brute force attacks
Brute forcing is a simple concept: one continuously tries to log in to a webpage or server log-in prompt like SSH with a high number of random username and password combinations. - OpenSSH - ArchWiki
If it should happen - there is no other way than reinstalling your system - and learn from it.
Thanks for this. I have installed ufw and configured it to allow a high number port for ssh then reconfigured sshd_config to use that port and it appears to be working.
It may be then that I was getting locked out of my account legitimately because attackers were trying to brute force in. In that case, it would not be a faillock problem but faillock actually doing its job to protect.
2 Likes
Running port scan on remote systems and brute-forcing passwords is a lucrative business. Only shady VPS providers allow their users to run port scanning from the rented server. Most VPS providers has - as a part of the agreement - a clause that such activity is banned and if caught it results in an immediate take-down - no refunds.
Of course there can be legitimate use of it - e.g. as a part of a penetration - which is also a profitable business.
But done rest - check your logs from time to time - I run a system which I only occationally use from outside and I used the deception technique but they eventually found that port too.
So lesson number two - always keep an eye on your logs - no matter if its a web server or shell server and no matter if it is self-hosted or rented - always keep an eye on your logs.
EDIT:
I swept up two post targeting SSH from the archived forum and made them into one.
They are my notes on the steps I took to secure public SSH instances on VPS I had some fun with.
Since securing my ssh I have not seen this problem show up again. I’ll probably keep this open for a few more days and if it does not show up again, I think we might have our answer. Thanks linux-aarhus.
Marked as solved.
Looks like the problem is back and I only bought myself a few days before a botnet found the new port. There are different IP addresses in every attempt about every 30s even with my firewall on and on a unique port.
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.