Hi everyone!
There is a task. “Run a specific sudo script right after entering “execution (second) password” on the login screen.”
The first idea that came to my mind was to somehow “add” a second password for the main user of the system and when logging in to the system using this password, run the sudo script. But I have no idea how feasible this option is. Perhaps someone has encountered a similar issue or knows the answer.
Thanks in advance!
Welcome to the forum!
This makes no sense at all. If it requires sudo, then why should it be run when an unprivileged user logs in?
There are ways of running root-privilege stuff at system boot via systemd units. Perhaps you should look into that.
As @maycne.sonahoz says, what is it that you are trying to achieve?
I second the What do you want to do question.
This is a potential dangerous action your are planning
Better to use a systemd unit to run a script.
If you must have a specific user logging in for the script to be executed - you could create it as a user service.
You could take it as far as creating a rule for the script in question to allow it to run as root without interaction.
But having such tasks on your system is a beg for disaster … you should consider carefully the implications and the pros and cons for the task at hand.
1 Like
First of all, thank you for your activity!
I want to make or find an analogue of “Luks Nuke”. The script is simple, you enter the correct user password - you get access, you enter the “Nuke” password - the script runs with commands.
There will be commands in the script that require sudo rights.
There is no such analogue but there is the same one described here for arch based distros Cryptsetup Nuke Keys Patch – Arch Linux Personal Setup
Why ask for help if the script is simple?
Thanks for your answer, I’ll try Luks Nuke later.
I probably did not describe the problem I want to solve very clearly.
I need to be able to enter another password at the time of the prompt to enter the user’s password to log in, which will launch the script and, for example, shut down the computer.
This functionality is needed on the start screen (after booting the system) and on the lock screen (Win + L).
By default, whatever greeter you are using, display manager, session manager or via TTY … once is started and selected the user or type the user name in TTY, it will read the users and recognize the password of that user, and if you type the wrong password, it will report that as Login failed or Login incorrect.
In some cases there is a limit of how many times you can type the wrong password and it will lock, for some time, the ability to log in. See your /etc/security/faillock.conf for more options of that module, that is owned by pam package.
Maybe you can ask pam developers to add more options for different scenarios, or go by yourself and use pam_tally2 and pam_exec as described here https://unix.stackexchange.com/questions/511503/how-to-configure-a-shutdown-at-the-xth-wrong-entered-password
2 Likes
There is no way to authenticate using another password or user on the lock screen, except when you want to switch to another user account…
All accounts have only 1(one) password they can be authenticated with, there is no alternate password mechanism…
So you only have one option for your use-case:
- Create another user account with your script as login shell.
Then login into that user account when you want the script to be executed.
Yes it’s imposible on Unix/Linux to create autorun viruses/hackers without explicit approval/interaction of the operating human. 
That you cannot do - due to the requirement of entering a username password combo.
A viable method is described by @bogdancovaciu there is no other easy way to script this.
You could implement something which requires an sdcard to be present to unlock your luks encrypted volume or you could separate the luks keys onto sdcard and your loader to an usb stick which would make it impossible to access without all elements present.
That’s what I initially said
Uhmmm sorry no…
A user service is something totally different as a script used as login-shell 
a user login is a singleton - thus there is no method of implementing a choice between passwords which leads to the suggestion of a specific user executing the script upon login
having a user running a service or a script upon login implies the user has been created thus my comment implied the user had been created beforehand
the following comments showed that the goal to accomplish is something like preventing one entity from forcing another entity to provide access to the system at hand. Instead the second entity provides a nuke password which then should shutdown the system to provide obstacles for the agression party in their attempt to access the system’s data.
The nuke-it-login method is often shown in older spy movies but it is not easily implemented using Linux systems.
One viable method - besides @bogdancovaciu reference to patching crypt-setup - is two logins where you - if forced - supply the wrong login credentials causing the system to shutdown - perhaps nuke the luks keys - which you - of course - have backed-up somewhere safe - likely an micro sd card inside a chess piece on your chessboard.
To increase the chance of success you should start x manually after login - thus hiding which usernames could possibly be available.
If the whole point is to prevent access to the system by untrusted users, then you should not use any luks-header on the HD and neither an EFI partition, just boot from an USB-stick that decrypts the encrypted HD
Anyhow we are derailing from the Topic-Title…
I think this module is what OP is looking for
Before you even think of implementing it - be sure you can recover
https://www.cyberciti.biz/security/how-to-backup-and-restore-luks-header-on-linux/
You can choose from one of two options:
Using two removable media previous your own password
There are two removable media which work as keys: the auth key and the panic key. The auth key will let you pass to the password prompt whereas the panic key, if provided, will securely erase the LUKS header, rendering the data unreadable.
Using two passwords previous your own password
There are two passwords you are able to set: the key password and the panic password. The key password will let you pass to the original password prompt whereas the panic password, if provided, will securely erase the LUKS header, rendering the data unreadable.
This is exactly what I was looking for, thank you!
I don’t understand why TriMoon put a laughing smiley face on your post 
Possibly the warning - the thought of what might happen if one does not have a backup of the luks header.
Thank you for your concern, indeed. I have all possible backups and if anything happens I will be able to recover.
Things are getting more and more interesting with pam_panic because I can’t even install this module.
My system:
OS: Manjaro Linux x86_64
Kernel: 6.1.7-1-MANJARO
Shell: bash 5.1.16
DE: Plasma 5.26.5
There is a conflict between cunit 2.1.3.3 and bcunit-cunit-compat (needed for pam_panic).
These are the errors when trying to install pam_panic:
pam_panic-0.3.4.tar.gz … Done (WARNING: this key has expired.)
Suite: Suite pam_panic_authdevice
Test: Authenticate with good device? …passed
Test: Authenticate with bad device? …passed
Test: Authenticate with no device? …passed
Suite: Suite pam_panic_reject
Test: Serious function? …passed
Test: Reboot function? …passed
Test: Poweroff function? …passed
Test: Nothing at all function? …passed
Suite: Suite pam_panic_pw
Test: Write a password into a file? …passed
Test: Check password file with correct passwords? …make[1]: *** [Makefile:717: all] Segmentation error (memory dump done)
make[1]: exit directory “/var/tmp/pamac-build-USER/pam_panic/src/pam_panic-0.3.4/test”
make: *** [Makefile:866: test] Error 2
==> ERROR: Check() failed.
Abort…
Don’t know how to solve it.