Script not running on arch linux

[bleck9999]

I have set up pam_duress, but when a duress password is used it doesn't seem to run the script and just logs in without doing anything.

blecc@toweringboi ~$ cat ~/.duress/hello.sh 
#!/bin/sh
echo "Hello World"

blecc@toweringboi ~$ duress_sign ~/.duress/hello.sh 
Password:  # 1234
Confirm:  # 1234
Reading .duress/hello.sh, 30...
Done
818034A48A634AEACAB6753A80E2160D42EE25C44791A083D5F8727E2B3D7A99
blecc@toweringboi ~$ chmod 400 ~/.duress/hello.sh.sha256 
blecc@toweringboi ~$ ls -l ~/.duress/
total 8
-r-x------ 1 blecc blecc 30 Sep 30 16:48 hello.sh
-r-------- 1 blecc blecc 32 Sep 30 16:51 hello.sh.sha256
blecc@toweringboi ~$ ssh blecc@localhost
blecc@localhost's password:  # 1234
< no hello world >
Last login: Fri Sep 30 16:46:36 2022 from ::1 
blecc@toweringboi ~$ 

Using an incorrect (non-duress) password still fails to log in at all, but no input causes the script to actually run. I have tried putting the script in /etc/duress.d instead of ~/.duress and using a non-outputting check (eg touching a file in /tmp/) with the same result.

[DusanLesan]

Same behavior for me. I have not even noticed that before since I only use duress to have 2 login passwords

[zhum]

The same bug on Ubuntu 22.04.1. Duress password works, but no script is executed.

ls -la ~/.duress/
total 16
dr-x------  2 szhumatiy domain-users 4096 Oct  5 15:42 .
drwxr-xr-x 43 szhumatiy domain-users 4096 Oct  5 15:45 ..
-r-x------  1 szhumatiy domain-users   89 Oct  5 15:45 logit.sh
-r--------  1 szhumatiy domain-users   32 Oct  5 15:34 logit.sh.sha256

Script itself is working, if started from command line. I use debug build, but no debug messages or logs can be found...

[nuvious]

I'll give this a shot; will spin up a 22.04.1 to try and reproduce and/or look into Arch. I'm less experienced with arch but if I can reproduce the issue in Ubuntu that may resolve it in Arch as well; either way will try to reproduce/keep it open until resolved.

[nuvious]

@zhum, I spun up a fresh version of ubuntu server and was unable to reproduce the behavior you're describing. Couple questions:

• Do you have rsyslog installed? pam-duress outputs to /var/log/syslog by default and can be grepped with pam_test.
• Are you using a desktop environment or is this a headless server?
• Can you try the script used in the intro and see if that works?

@bleck9999 I'm getting an arch distro up to see if I can reproduce your issue with the arch guide that's currently in the repo

@DusanLesan, what distro are you using and/or is it headless or does it have a desktop environment?

[DusanLesan]

@nuvious I use Arch with dwm window manager. I get several similar errors when doing make

[nuvious]

@nuvious I use Arch with dwm window manager. I get several similar errors when doing make

Those appear to just be warnings. Looks like from what yoh screenshotted that the compilation succeeded. make install should copy a file called pam_duress.so to your module directory. Can you do a find / -iname pam_duress.so 2>/dev/null and supply that output?

[DusanLesan]

Those appear to just be warnings. Looks like from what yoh screenshotted that the compilation succeeded. make install should copy a file called pam_duress.so to your module directory. Can you do a find / -iname pam_duress.so 2>/dev/null and supply that output?

The security module must be there as it is able to authenticate using duress password. This is output of find / -iname pam_duress.so 2>/dev/null: I have supplied warning messages from the make process in case they might be useful to you and errors in function called run_shell_as does look suspicious to me

[zhum]

Sorry for delay. I've checked it on my another laptop with ubuntu 22.04 and it work well there. But on my first laptop I still see strange situation: I can authenticate with pam_duress, but the script is not executed and I cannot see any records in the log. Now I can see only such records:

Oct 24 16:58:45 sergzhum sudo: szhumatiy : problem with defaults entries ; TTY=pts/3 ; PWD=/home/szhumatiy/0_tmp/pam-duress ; USER=root ; 
Oct 24 16:58:45 sergzhum sudo: szhumatiy : TTY=pts/3 ; PWD=/home/szhumatiy/0_tmp/pam-duress ; USER=root ; COMMAND=/usr/local/bin/pam_test szhumatiy
Oct 24 16:58:45 sergzhum sudo: pam_unix(sudo:session): session opened for user root(uid=0) by szhumatiy(uid=361952834)
Oct 24 16:58:49 sergzhum pam_test: pam_krb5(check_user:auth): authentication failure; logname=szhumatiy uid=0 euid=0 tty= ruser= rhost=
Oct 24 16:58:49 sergzhum pam_test: pam_unix(check_user:auth): authentication failure; logname=szhumatiy uid=0 euid=0 tty= ruser= rhost=  user=szhumatiy
Oct 24 16:58:49 sergzhum pam_test: pam_sss(check_user:auth): Request to sssd failed. Connection refused
Oct 24 16:58:49 sergzhum sudo: pam_unix(sudo:session): session closed for user root

I have more complicated pam config here:

auth    [success=7 default=ignore]  pam_krb5.so minimum_uid=1000
auth    [success=6 default=ignore]  pam_fprintd.so max-tries=1 timeout=10 # debug
auth    [success=5 default=ignore]  pam_unix.so nullok try_first_pass
auth    [success=4 default=ignore]  pam_sss.so use_first_pass
auth    [success=3 default=ignore]  pam_ccreds.so minimum_uid=1000 action=validate use_first_pass
auth    [success=2 default=ignore]  pam_ccreds.so minimum_uid=1000 action=update
auth    [success=1 default=ignore]  pam_duress.so
# here's the fallback if no module succeeds
auth    requisite           pam_deny.so

And yes, here I've tried to use non-cached password for the script (re-signed it and tried).

[nuvious]

@zhum, interesting behavior. From the debug output it looks like pam_ccreds.so is succeeding potentially somehow. Have you tried explicitly clearing the cache for that? I'm unfamiliar with pam_sss/pam_ccreds but initial googling suggests maybe a cache in /var/cache/.security.db needs to be removed or explicitly clearing the pam_sss cache via the sss_cache utilty may ensure nothing is being cached(link)?

In any case with one Ubuntu 22.04.01 laptop working with expected behavior I'm not sure this would be a module specific issue and may just require some more configuration tweaking.

Try putting pam_duress underneath pam_unix.so directly if you haven't yet; I'm unsure if that would break any use of cached credenitals if your ldap/kerberos server is unreachable but it would make pam_duress the module immediately following pam_unix which if an alternate password was being used then it would skip past all the credential caching modules and authenticate the user while also running the pam-duress specific scripts.

[zhum]

Cool! Deletion of /var/cache/.security.db really helped! Now all is working as needed. It seems strange to me, because I tried to change passwords for duress, just to skip caching. But anyway - it works now. You can add this point to the troubleshooting guide.

[5unr153]

I had a same issue, but i didn't even have /var/cache/.security.db. I checked journalctl and found error at second line .

Apr 28 15:40:07 localhost sudo[3201]: Executing /home/localuser/.duress/test.sh.
Apr 28 15:40:07 localhost sudo[3201]: Could not run script /home/localuser/.duress/test.sh, Bad address.

As we see in source code, the module use execv(script, script_args); function at line 293 of duress.c. This function need NULL value as string terminator, but script_args variable inits like this char *script_args[] = {};

So, using solution from here, i just replace char *script_args[] = {}; to char *script_args[] = {(char*)0}; rebuild and it works.

[nuvious]

Closing this issue with thanks to @5unr153 and @DusanLesan!