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 ?
Huh…this is a thread no ?
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.
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
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 18.104.22.168 V 2021-04-01 21:44:54 RHOST 22.214.171.124 I 2021-04-01 21:44:58 RHOST 126.96.36.199 I 2021-04-01 21:45:00 RHOST 188.8.131.52 I 2021-04-01 21:46:40 RHOST 184.108.40.206 I 2021-04-01 21:46:43 RHOST 220.127.116.11 I 2021-04-01 21:47:29 RHOST 18.104.22.168 I 2021-04-01 21:51:05 RHOST 22.214.171.124 V 2021-04-01 21:51:56 RHOST 126.96.36.199 V 2021-04-01 21:52:02 RHOST 188.8.131.52 V 2021-04-01 21:56:27 RHOST 184.108.40.206 V 2021-04-01 21:57:18 RHOST 220.127.116.11 V 2021-04-01 21:57:22 RHOST 18.104.22.168 V 2021-04-01 21:58:06 RHOST 22.214.171.124 V 2021-04-01 21:58:13 RHOST 126.96.36.199 V 2021-04-01 21:59:00 RHOST 188.8.131.52 V 2021-04-01 21:59:04 RHOST 184.108.40.206 V 2021-04-01 21:59:07 RHOST 220.127.116.11 V 2021-04-01 21:59:52 RHOST 18.104.22.168 V 2021-04-01 22:00:45 RHOST 22.214.171.124 V 2021-04-01 22:00:48 RHOST 126.96.36.199 V 2021-04-01 22:00:52 RHOST 188.8.131.52 V 2021-04-01 22:01:36 RHOST 184.108.40.206 V 2021-04-01 22:01:40 RHOST 220.127.116.11 V 2021-04-01 22:01:43 RHOST 18.104.22.168 V 2021-04-01 22:02:30 RHOST 22.214.171.124 V 2021-04-01 22:02:34 RHOST 126.96.36.199 V 2021-04-01 22:02:38 RHOST 188.8.131.52 V 2021-04-01 21:41:26 RHOST 184.108.40.206 I 2021-04-01 21:42:14 RHOST 220.127.116.11 I 2021-04-01 21:42:17 RHOST 18.104.22.168 I 2021-04-01 21:42:21 RHOST 22.214.171.124 I 2021-04-01 21:43:07 RHOST 126.96.36.199 I 2021-04-01 21:43:11 RHOST 188.8.131.52 I 2021-04-01 21:44:06 RHOST 184.108.40.206 I 2021-04-01 21:44:09 RHOST 220.127.116.11 I 2021-04-01 21:44:13 RHOST 18.104.22.168 I 2021-04-01 22:03:24 RHOST 22.214.171.124 V 2021-04-01 22:03:27 RHOST 126.96.36.199 V 2021-04-01 22:03:31 RHOST 188.8.131.52 V 2021-04-01 21:37:50 RHOST 184.108.40.206 I 2021-04-01 21:37:54 RHOST 220.127.116.11 I 2021-04-01 21:37:58 RHOST 18.104.22.168 I 2021-04-01 21:38:43 RHOST 22.214.171.124 I 2021-04-01 21:38:46 RHOST 126.96.36.199 I 2021-04-01 21:38:50 RHOST 188.8.131.52 I 2021-04-01 21:39:40 RHOST 184.108.40.206 I 2021-04-01 21:39:44 RHOST 220.127.116.11 I 2021-04-01 21:39:47 RHOST 18.104.22.168 I 2021-04-01 21:40:32 RHOST 22.214.171.124 I 2021-04-01 21:40:36 RHOST 126.96.36.199 I 2021-04-01 21:40:38 RHOST 188.8.131.52 I 2021-04-01 21:41:20 RHOST 184.108.40.206 I 2021-04-01 21:41:24 RHOST 220.127.116.11 I 2021-04-01 21:43:14 RHOST 18.104.22.168 I 2021-04-01 21:45:46 RHOST 22.214.171.124 I 2021-04-01 21:45:50 RHOST 126.96.36.199 I 2021-04-01 21:45:53 RHOST 188.8.131.52 I 2021-04-01 21:46:47 RHOST 184.108.40.206 I 2021-04-01 21:47:32 RHOST 220.127.116.11 I 2021-04-01 21:47:36 RHOST 18.104.22.168 I 2021-04-01 21:48:24 RHOST 22.214.171.124 I 2021-04-01 21:48:26 RHOST 126.96.36.199 I 2021-04-01 21:48:29 RHOST 188.8.131.52 I 2021-04-01 21:49:18 RHOST 184.108.40.206 V 2021-04-01 21:49:22 RHOST 220.127.116.11 V 2021-04-01 21:49:25 RHOST 18.104.22.168 V 2021-04-01 21:50:10 RHOST 22.214.171.124 V 2021-04-01 21:50:14 RHOST 126.96.36.199 V 2021-04-01 21:50:17 RHOST 188.8.131.52 V 2021-04-01 21:51:03 RHOST 184.108.40.206 V 2021-04-01 21:51:09 RHOST 220.127.116.11 V 2021-04-01 21:51:58 RHOST 18.104.22.168 V 2021-04-01 21:52:49 RHOST 22.214.171.124 V 2021-04-01 21:52:52 RHOST 126.96.36.199 V 2021-04-01 21:52:56 RHOST 188.8.131.52 V 2021-04-01 21:53:41 RHOST 184.108.40.206 V 2021-04-01 21:53:45 RHOST 220.127.116.11 V 2021-04-01 21:53:48 RHOST 18.104.22.168 V 2021-04-01 21:54:36 RHOST 22.214.171.124 V 2021-04-01 21:54:39 RHOST 126.96.36.199 V 2021-04-01 21:54:43 RHOST 188.8.131.52 V 2021-04-01 21:55:28 RHOST 184.108.40.206 V 2021-04-01 21:55:32 RHOST 220.127.116.11 V 2021-04-01 21:55:34 RHOST 18.104.22.168 V 2021-04-01 21:56:20 RHOST 22.214.171.124 V 2021-04-01 21:56:23 RHOST 126.96.36.199 V 2021-04-01 21:57:25 RHOST 188.8.131.52 V 2021-04-01 21:58:09 RHOST 184.108.40.206 V 2021-04-01 21:59:55 RHOST 220.127.116.11 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
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
I do not recognize the IP Address
It looks like I actually have several ssh keys in my
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.