sshd support

[imThief]

Hello! It will be nice if your very useful module got ssh support :)

This is the plain local login Mar 1 18:45:56 fluffy login[20716]: pam_e4crypt: Generating key with salt length 16 from file '/etc/pam.d/fox' Mar 1 18:45:56 fluffy login[20716]: pam_e4crypt: Inserting key with reference ext4:826f76abc8542ebc as 1000:10 Mar 1 18:45:56 fluffy login[20716]: pam_unix(login:session): session opened for user fox(uid=1000) by LOGIN(uid=0)

And this is the login log via ssh Mar 1 18:45:37 fluffy sshd[20765]: pam_e4crypt: Generating key with salt length 16 from file '/etc/pam.d/fox' Mar 1 18:45:37 fluffy sshd[20762]: Accepted keyboard-interactive/pam for fox from 10.10.10.4 port 52155 ssh2 Mar 1 18:45:37 fluffy sshd[20762]: pam_e4crypt: Failed to retrieve key list!

As i see, ssh key insertion doesn't happens in the via ssh login case...

[neithernut]

Do you happen to use an ssh-key? In this case, PAM will never see your password and hence pam_e4crypt will not be able to derive a key to add to the keyring. I'm not sure whether it's feasible to make this module work in such scenarios. I will investigate, but don't expect any outcome anytime soon. As in this year. (My maintainership of this module is... lacking) Btw: you'll find that kerberos or AD-protected network mounts exhibit a similar limitation.

If you authenticate via a (plain) password, this should work and you likely suffer from some missconfiguration. It's kind of hard to tell, however, just from those logs.

[imThief]

I assumed that, so tried both methods: with and without key - no difference, sadly. Misconfiguration? Maybe, but its so simple that i can't even imagine what kind of mistake i could do in 2 strings :) Don't have that laptop at my hand at this moment, but will post full pam (include-recursive) config as soon as i can... Don't you mind to take a look? And many thanks for the reply! ^_^

[neithernut]

Mh... given your logs, at least the authentication stage is configured correctly. And also, actually, that the passphrase does make it to the PAM module (which I could have made out earlier, if I did pay attention, duh). Assuming that you put both the "auth" and the "session" line in the same file, the problem probably lies somewhere else. It may actually be related to #39, in that internal information is not properly forwarded. Which makes me interested in your config, especially the differences between the services used by local login (i.e. the login file in /etc/pam.d) vs. login via ssh (should be sshd). I'd check the differences between them by resolving all the "include" lines manually for both cases, recursively, and then compare those two. Obviously in separate files, not your system config. You're welcome to either do so yourself or make the contents of your /erc/pam.d available somewhere. If you did not modify your PAM config too much, you can also just point me to the Linux distro you are using and post a diff of your config/describe where exactly you inserted and additional lines after installation.

[imThief]

Hello! Sorry about late, i'm using linux gentoo distribution and i use default (except pam_e4crypt.so itself changes) pam configuration. Here is my config

~ # cat /etc/pam.d/sshd auth include system-remote-login account include system-remote-login password include system-remote-login session include system-remote-login

~ # cat /etc/pam.d/system-remote-login auth include system-login account include system-login password include system-login session include system-login

~ # cat /etc/pam.d/system-login auth required pam_shells.so auth required pam_nologin.so auth include system-auth account required pam_access.so account required pam_nologin.so account include system-auth password include system-auth session optional pam_e4crypt.so session optional pam_loginuid.so session required pam_env.so envfile=/etc/profile.env session optional pam_lastlog.so silent session include system-auth session optional pam_motd.so motd=/etc/motd session optional pam_mail.so -session optional pam_elogind.so

~ # cat /etc/pam.d/system-auth auth required pam_env.so auth requisite pam_faillock.so preauth auth [success=1 default=ignore] pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail auth optional pam_e4crypt.so saltpath=/etc/pam.d auth optional pam_permit.so account required pam_unix.so account required pam_faillock.so account optional pam_permit.so password required pam_passwdqc.so config=/etc/security/passwdqc.conf password required pam_unix.so try_first_pass use_authtok nullok sha512 shadow password optional pam_permit.so session required pam_limits.so session required pam_env.so session required pam_unix.so session optional pam_permit.so

About pambase: [I] sys-auth/pambase Available versions: 20201103^b ~20210201.1^b *999999999l^b {caps debug elogind gnome-keyring homed minimal mktemp +nullok pam_krb5 pam_ssh +passwdqc pwhistory pwquality securetty selinux +sha512 systemd} Installed versions: 20201103^b(02:32:39 PM 02/26/2021)(elogind nullok passwdqc sha512 -caps -debug -gnome-keyring -minimal -mktemp -pam_krb5 -pam_ssh -pwhistory -pwquality -securetty -selinux -systemd) Homepage: https://github.com/gentoo/pambase Description: PAM base configuration files

Note about 'optional' for pam_e4crypt.so: unfortunately i can't login via ssh at all (due to module error in session part) if i put 'required' here. Anyway as i noticed there is no difference for local login.

[neithernut]

Thanks for the input! I think you omitted the login and system-local-login files, but these should be identical to sshd and system-remote-login, respectively, on a Gentoo installation. So, it looks like there is indeed no practical difference between the configuration for local and ssh login. Which (probably) means that the difference lies in how PAM is invoked by login (or you session manager/whatever) and sshd. My current hypothesis is that the auth and session phase are performed by separate processes in the ssh case. I'll probably be able to confirm this myself in the "near" future. If my hypothesis is correct, I'll need to come up with another channel for passing around the key. Which is tricky, since you definitely don't want it to leak. For reference, I'd appreciate if you could also tell me what version of ssh (net-misc/openssh) and sys-libs/pam you are using.

Note about 'optional' for pam_e4crypt.so: unfortunately i can't login via ssh at all (due to module error in session part) if i put 'required' here. Anyway as i noticed there is no difference for local login.

That's a perfectly sensible choice.

[imThief]

I'm sorry about my late feedback, i have some new info related to this problem. Recently i've successful logged in via ssh and got a key insertion with my current pam configuration. Nothing was changed except system libs/ssh version and login process went fine. Now i think that this was not pam_e4crypt-related problem, therefore this issue can be closed, imho. Thank you for your support... and patience :)

P.S. My current software versions - if the question is still actual: net-misc/openssh-8.8_p1-r4 sys-libs/pam-1.5.1_p20210622-r1