First your opinion is yours and doesn’t make things more real, as much as you would like to.
Second I didn’t reply to you, I replied to benm asking where to report the bug, and explained there is nothing to report unless someone figures what the bug actually is. It is you who seem to not understand this basic concept.
Understando? or no understando?
It is simple. We have to know the root cause of the problem to report it as a problem.
Huh…this is a thread no ?
This is not the place here for private message, this is the place to share with everybody, one of the root reason of existence of each single open source community, maybe you missed something.
Toi comprendre moi ?
Ran into same problem last week. It was only when I was typing in something later that I realised I had a faulty Bank of keys, poor or intermittent contact. If it happens again,connect a spare/different keyboard.
This is not the problem, the same problem persists when I ssh from another computer or when I use the on screen keyboard. I also use this keyboard on two other computers, shared via Barrier.
Some time ago, I had the same problem, it disappeared when I uninstalled the NVIDIA proprietary drivers and went back to open source video drivers.
As my laptop consumes much more power with the open source drivers, I retried installing the NVIDIA drivers, and I have not noticed the problem anymore.
That is interesting, but in this case, I am using Intel integrated graphics.
Check if faillock hits:
I’ve read reports in the past mentioning fingerprint sensors inadvertently triggering faillock mechanism leading to seemingly not working correct passwords.
Just a note the issue I was talking about earlier, was not for login to the session, but was happening when running commands with sudo.
I described what happens to me on post #7 on this thread with a small journalctl extract.
It’s not related to any DE because i use XFCE and the OP use KDE.
It often happens to me when using Mugshot (but not always), and not necessarily, there are other cases when it happened, as the OP as well.
@linux-aarhus has suggested to have a different password for root and user. Indeed, i have both password the same. I will change that and make some tests to see what happens.
Please read the linked post and the ArchWiki article (again) - faillock mechanism is not depending on the desktop environment. /etc/security/faillock.conf is owned by pam package and that would be installed on all manjaro spins.
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
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