двойной смысл логина

К одному id (а именно id определяет аккаунт, а не юзернейм) можно прицепить несколько разных юзернеймов, каждый со своим паролем. Делать через useradd/usermod/vim. Права на файлы определяются по id, - права на них у юзернеймов будут одинаковы. Разделить действия можно будет через sudo.

Но вообще лучше использовать двух разных полноценных юзеров. Иначе юзернеймы, прицепленные к одному id по разным паролям смогут друг другу подсирать.

Перечитал тут реквест. Если ты хочешь чтоб именно у одного _юзернейма_ было два разных пароля при логине - дефолтная линуксовая аутентификация через shadow этого не умеет. Смотри в лдап/радиус/еще-чвонибудь.

Я думаю ему не это нужно, а тревожный пароль - при вводе затереть данные.

https://en.wikipedia.org/wiki/Pluggable_authentication_module

именно.

Данные на отдельном шифрованном разделе. Тревожная кнопка: RESET. Тока учти, что у некоторых с собой могут оказаться паяльники.

Данные на отдельном шифрованном разделе. Тревожная кнопка: RESET.

поясни. не понял...

Он хочет именно антипаяльную защиту - ввел не тот пасс и заголовки затерлись. Если сервак удаленный или гэбня тупая, это даже сработает.

антипаяльную защиту

спрятать свою тушку туда, где кровавая гэбня не дотянется
благо это не АНБ, людей по планете не крадёт и без суда в тюрьмах годами не гноит

Почему бы не пропатчить код отвечающий за экран входа?

Написать свой pam модуль аутентификации. Кажется в Kali даже что то такое уже написано

https://www.kali.org/how-to/emergency-self-destruction-luks-kali/

хорошо, что есть в Kali, и плохо что ТОЛЬКО В Kali... сам факт использования Kali, как бы намекает, и это плохо...

Ну, можно запатчить же свой cryptsetup и все дела. pam_exec еще есть же

Плюсую PAM и отдельно pam_exec.

Он хочет типа panic button. Чтобы в случае опасности залогиниться другим паролем, который удалит его коллекцию ЦП и запустит закачку MLP. В итоге и требования нападающего он выполнит (допустим, ему предоставили выбор - ввод пароля в компьютер или ввода паяльника сами знаете куда), и улик не будет.

Единственное что нужно отметить, что скорее всего в случае жопы дамп диска уже будет снят, и просить ввести пароль будут в вот таких вот тусклых условиях. Это нужно иметь в виду, и не особо расчитывать на тревожную кнопку. Чуть полезнее иметь метаданные на внешнем носителе, а контейнер иметь в неразмеченной области..

полезнее иметь метаданные на внешнем носителе

подскажите, куда копать?

Ну, например, писать файлы в конкретную область диска при помощи dd, а в отдельное место записывать, с какого по какой блоки расположены нужные данные.

Вот пример шифрования носителей тремя ключами (выдержка из man geli(8)):

The example below shows how to configure two providers which will be
     attached on boot (before the root file system is mounted).	 One of	them
     is	using passphrase and three keyfile parts and the other is using	only a
     keyfile in	one part:

	   # dd	if=/dev/random of=/dev/da0 bs=1m
	   # dd	if=/dev/random of=/boot/keys/da0.key0 bs=32k count=1
	   # dd	if=/dev/random of=/boot/keys/da0.key1 bs=32k count=1
	   # dd	if=/dev/random of=/boot/keys/da0.key2 bs=32k count=1
	   # geli init -b -K /boot/keys/da0.key0 -K /boot/keys/da0.key1	-K /boot/keys/da0.key2 da0
	   Enter new passphrase:
	   Reenter new passphrase:
	   # dd	if=/dev/random of=/dev/da1s3a bs=1m
	   # dd	if=/dev/random of=/boot/keys/da1s3a.key	bs=128k	count=1
	   # geli init -b -P -K	/boot/keys/da1s3a.key da1s3a

     The providers are initialized, now	we have	to add these lines to
     /boot/loader.conf:

	   geli_da0_keyfile0_load="YES"
	   geli_da0_keyfile0_type="da0:geli_keyfile0"
	   geli_da0_keyfile0_name="/boot/keys/da0.key0"
	   geli_da0_keyfile1_load="YES"
	   geli_da0_keyfile1_type="da0:geli_keyfile1"
	   geli_da0_keyfile1_name="/boot/keys/da0.key1"
	   geli_da0_keyfile2_load="YES"
	   geli_da0_keyfile2_type="da0:geli_keyfile2"
	   geli_da0_keyfile2_name="/boot/keys/da0.key2"

	   geli_da1s3a_keyfile0_load="YES"
	   geli_da1s3a_keyfile0_type="da1s3a:geli_keyfile0"
	   geli_da1s3a_keyfile0_name="/boot/keys/da1s3a.key"

Там есть интересная опция:

kill       This command should be used only in emergency situations.  It
                will destroy all copies of the Master Key on a given provider
                and will detach it forcibly (if it is attached).  This is
                absolutely a one-way command - if you do not have a metadata
                backup, your data is gone for good.  In case the provider was
                attached with the -r flag, the keys will not be destroyed,
                only the provider will be detached.

                Additional options include:

                -a  If specified, all currently attached providers will be
                    killed.

Общий случай использования (описано на русском): https://www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/disks-encrypting.html

Вот ещё способ настройки «тревожной кнопки»: http://storm.in.ua/a59/GELI-sozdanie-zaschischennogo-i-byistrounichtojimogo-f...