Very often the password is incorrect

sdslot · 2024-03-19 07:37:42

Greetings.
Please help me, I’ve been suffering for a week and can’t find the reason.
In the password entry windows, be it sudo or in the bootloader, when entering the encrypt password, 90% of the times it says the wrong password, although in any other line where I see the text entered the password is correct. Sometimes it helps to play with Numlock on/off, sometimes when connecting another keyboard via USB, sometimes if it reboots several times, but this also does not always help.
Where to dig?

seth · 2024-03-19 08:07:33

* broken keyboard
---
* fat fingers
* broken memory (not RAM, yours)
---
* keyboard layout (non qwerty-safe password on a non-qwerty keyboard that is still in the default, qwerty, layout), but that's rather deterministic
* faillock, but not during the bootloader

wrt the qwerty situation, wayland ./. xwayland could be a problem, the easiest way to rule that out is w/ a qwerty safe password, in doubt

frostschutz · 2024-03-19 08:20:17

seth wrote:

* broken memory (not RAM, yours)

luks2 (argon2) is sensitive to bad ram, and some intel cpus misbehave on turbo/overclock ( https://www.radgametools.com/oodleintel.htm )

Don't use luksChangeKey on such a system. It might result in bad key material which can no longer be unlocked by anything.

Use luksAddKey to add a simple passphrase for testing.

Run a memtest, and check bios settings.

Last edited by frostschutz (2024-03-19 08:20:31)

seth · 2024-03-19 08:31:35

That had to come

But wrt

In the password entry windows, be it sudo […] 90% of the times it says the wrong password, although in any other line where I see the text entered the password is correct.

I had ruled this out b/c at the point where hashing a password is affected, one would probably get memory errors across the board and a completely unstable system
(And the two members of that group were meant as a rather unlikely joke)

frostschutz · 2024-03-19 08:52:14

seth wrote:

I had ruled this out b/c at the point where hashing a password is affected, one would probably get memory errors across the board and a completely unstable system

The LUKS2/badram issue pops up quite often recently and memtest does find errors afterwards. Unfortunately whatever the cause it's not enough to make the system unstable as a whole.

sdslot · 2024-03-19 10:39:00

seth wrote:

That had to come
But wrt
In the password entry windows, be it sudo […] 90% of the times it says the wrong password, although in any other line where I see the text entered the password is correct.
I had ruled this out b/c at the point where hashing a password is affected, one would probably get memory errors across the board and a completely unstable system
(And the two members of that group were meant as a rather unlikely joke)

I ran a RAM test and it showed no errors.
I have a laptop with an 11th Gen Intel i7-1165G7 processor
There is nothing about overclocking or anything else in the BIOS.
The gap is definitely not in my hands when entering))
After 5-10 reboots I manage to get into the system.
Moreover, sometimes I can enter the password luks and then the password in the tty no longer fits and the reboot occurs again.
Maybe something can be found in the log?

sdslot · 2024-03-19 11:05:07

Looks like I've figured it out.
With a simple password everything works fine.
With passwords containing characters such as "@#" it gave an error.
Why is there a problem with symbols?

frostschutz · 2024-03-19 11:12:43

You could run a test on an empty file just to make sure cryptsetup itself is working in general.

truncate -s 16M lukstest.img
echo -n 123 | cryptsetup luksFormat lukstest.img
for i in $(seq 100)
do
    echo -n 123 | cryptsetup open --test-passphrase lukstest.img lukstest && echo OK $? || echo FAIL $?
done

Should print OK 100 times.

If that works, it's probably another issue.

Maybe your keyboard is detected late so you end up typing half a passphrase without noticing? Just to make sure the keyboard is alive, press enter on the first attempt before typing it for the 2nd attempt, does that work?

Are you using UUIDs for your devices? Otherwise it could be a mixup (if you got another LUKS container with a different pass, e.g. sda1 vs sdb1).

You could patch cryptsetup to show the passphrase it's trying to use, just for debugging purposes.

Otherwise not really many ideas...

With passwords containing characters such as "@#" it gave an error.
Why is there a problem with symbols?

Are you using US keyboard layout or something else?

If you're using non-ascii symbols like § ° it could also be a charset issue.

Last edited by frostschutz (2024-03-19 11:14:10)

sdslot · 2024-03-19 11:22:14

frostschutz wrote:

You could run a test on an empty file just to make sure cryptsetup itself is working in general.
truncate -s 16M lukstest.img
echo -n 123 | cryptsetup luksFormat lukstest.img
for i in $(seq 100)
do
    echo -n 123 | cryptsetup open --test-passphrase lukstest.img lukstest && echo OK $? || echo FAIL $?
done
Should print OK 100 times.
If that works, it's probably another issue.
Maybe your keyboard is detected late so you end up typing half a passphrase without noticing? Just to make sure the keyboard is alive, press enter on the first attempt before typing it for the 2nd attempt, does that work?
Are you using UUIDs for your devices? Otherwise it could be a mixup (if you got another LUKS container with a different pass, e.g. sda1 vs sdb1).
You could patch cryptsetup to show the passphrase it's trying to use, just for debugging purposes.
Otherwise not really many ideas...
With passwords containing characters such as "@#" it gave an error.
Why is there a problem with symbols?
Are you using US keyboard layout or something else?
If you're using non-ascii symbols like § ° it could also be a charset issue.

user@arch ~> setxkbmap -print -verbose 10
Setting verbose level to 10
locale is C
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:      evdev
model:      pc105
layout:     us
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+us+inet(evdev)
geometry:   pc(pc105)
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+inet(evdev)"	};
	xkb_geometry  { include "pc(pc105)"	};
};

user@arch ~> locale -a
C
C.utf8
en_US.utf8
POSIX
ru_RU.utf8

user@arch ~> locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

seth · 2024-03-19 17:32:17

With a simple password everything works fine.
With passwords containing characters such as "@#" it gave an error.

Broken shift key?
Do capitals cause the same?
Does the other shift key work?
If you add "pwfeedback" to the sudoers Defaults, do you get an asterisk for the "problematic" keys?

Last edited by seth (2024-03-19 17:32:29)

seth · 2024-03-20 07:52:25

frostschutz wrote:

The LUKS2/badram issue pops up quite often recently and memtest does find errors afterwards. Unfortunately whatever the cause it's not enough to make the system unstable as a whole.

Do you have further links?
It deosn't fit the "heavy load" condition, but I wonder whether it might be related to the recent initramfs decompression issues.

sdslot · 2024-03-20 09:05:43

seth wrote:

With a simple password everything works fine.
With passwords containing characters such as "@#" it gave an error.
Broken shift key?
Do capitals cause the same?
Does the other shift key work?
If you add "pwfeedback" to the sudoers Defaults, do you get an asterisk for the "problematic" keys?

the buttons are fine. and I enter this password in any visible line, it is displayed correctly. I enter it on web resources and everything is ok.
Included asterisks, the number of characters entered corresponds.

I got rid of the problem for a while by changing it to a password without symbols but with capital letters and everything is ok (Shift works)

But the problem needs to be solved, because I can’t even connect via shh where passwords with symbols are used (((

seth · 2024-03-20 09:45:10

 ◉ openssl passwd -6 -salt xyz '#12345'                    
$6$xyz$F8CR.MUI2TzD2qpgUWezZ9gPLsa/44J6TYn2.5LZufFJR.3bSFV3NruPDtfIDWVUaq2J0lY953zDeFZ52psri/
◉ openssl passwd -6 -salt xyz '12345'                    
$6$xyz$8CMh..JKU5OH7Z9hM6kZlkUgX5ca/GhTKi5mnnZ1v.7VbhUT2BAkqj1sq8sck5TXsW1B/deRUk1qO/dbRJw9Z1

Try to change the password to "12345" and "#12345" and compare the entries in /etc/shadow to the above

Wrt the setxkamap outputs, you're not accidentally running a wayland session?
If this is indeed X11, try "xev -event keyboard" and enter one of the problematic symbols to see whether maybe some non-printable characters are generated, too.

Arch Linux

#1 2024-03-19 07:37:42

Very often the password is incorrect

#2 2024-03-19 08:07:33

Re: Very often the password is incorrect

#3 2024-03-19 08:20:17

Re: Very often the password is incorrect

#4 2024-03-19 08:31:35

Re: Very often the password is incorrect

#5 2024-03-19 08:52:14

Re: Very often the password is incorrect

#6 2024-03-19 10:39:00

Re: Very often the password is incorrect

#7 2024-03-19 11:05:07

Re: Very often the password is incorrect

#8 2024-03-19 11:12:43

Re: Very often the password is incorrect

#9 2024-03-19 11:22:14

Re: Very often the password is incorrect

#10 2024-03-19 17:32:17

Re: Very often the password is incorrect

#11 2024-03-20 07:52:25

Re: Very often the password is incorrect

#12 2024-03-20 09:05:43

Re: Very often the password is incorrect

#13 2024-03-20 09:45:10

Re: Very often the password is incorrect

Board footer