Description of problem: After enabling "ecryptfs" with: authconfig --enableecryptfs --update or authconfig --enableecryptfs --updateall logging in using ssh does not result in "Private" mounted. Note that "ecryptfs" is setup properly, so that "ecryptfs-mount-private" works. Furthermore the "ecryptfs" kernel module is loaded. Version-Release number of selected component (if applicable): authconfig-6.1.14-2.fc15.i686 How reproducible: Always Steps to Reproduce: 1. Load "ecryptfs" kernel module 2. Setup "ecryptfs" with "ecryptfs-setup-private" 3. Logout and login using ssh Actual results: Folder "Private" is not mounted. Expected results: Folder "Private" should be mounted. Additional info: I guess this is a "pam" issue, since "/etc/pam.d/sshd" does not seems to bare anything with "/etc/pam.d/postlogin". Nevertheless, it could be an "ecryptfs" issue.
/etc/pam.d/sshd must include postlogin stacks in the similar way to /etc/pam.d/login or /etc/pam.d/gdm.
openssh-5.6p1-33.fc15.1 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/openssh-5.6p1-33.fc15.1
Hi all, thanks for the quick response. I just installed (from Koji) the new "openssh" package. Still I've problem with mounting "Private" when logging in using "ssh". The reason seems to be that the user does not belong to the group "ecryptfs" when logged in with "ssh". From "root": $ id testuser uid=500(testuser) gid=500(testuser) groups=500(testuser),327(ecryptfs) From "testuser" via "ssh" $ id uid=500(testuser) gid=0(root) groups=500(testuser) And, of course, "ecryptfs-mount-private", from shell, does *not* work. If, from this point, I re-login using "su - testuser", then "id" returns the same as for "root". Nevertheless, "Private" is not mounted either, since "/etc/pam.d/su" seems not to bare anything with "postlogin" too. "ecryptfs-mount-private" works fine, after "su". So, summarizing, two issues: 1) User id is not as expected, after connecting with "ssh". 2) "authconfig" does not seem to setup "/etc/pam.d/su" properly. Thanks again, bye, pg
Authconfig does not setup individual service files. So the 2) must be reported as a separate bug against coreutils package. As for 1). What prints 'getent group ecryptfs'? However I am afraid that this problem might be related to the way openssh calls the pam functions.
Hi Tomas, (In reply to comment #4) > Authconfig does not setup individual service files. So the 2) must be reported > as a separate bug against coreutils package. OK, I'll do that. > As for 1). What prints 'getent group ecryptfs'? However I am afraid that this > problem might be related to the way openssh calls the pam functions. $ getent group ecryptfs ecryptfs:x:327:testuser Maybe, then also this issue should be re-assigned to "openssh"? Thanks, bye, pg
Ah! Silly me, this one was already re-assigned to "openssh". bye, pg
Hmm, that looks suspicious. I cannot reproduce the 1) here: I added an user to some supplementary group and when logging in the user through sshd the group is assigned properly.
Can you try with other users and other supplementary groups whether it does not work for them either or is it a problem only with the testuser and ecryptfs group?
Package openssh-5.6p1-33.fc15.1: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing openssh-5.6p1-33.fc15.1' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/openssh-5.6p1-33.fc15.1 then log in and leave karma (feedback).
Hi Tomas, I created another user and added it to "ecryptfs" group. Logging in using "ssh" does indeed work as expected, in respect of the "id" command. That is, the user id is reported correctly, belonging to the group "ecryptfs" too. Until this point, the user did not have "Private" setup with ecryptfs. If I setup it (ecryptfs-setup-private) then re-logging in with "ssh" results in the same issue as reported before, i.e. no gid "ecryptfs" and a funny gid=0(root). This last one is not supposed to be there. Nevertheless, I've to apologise (I'll write 100 times: "I should not report issues late at night"), since I failed to report another phenomenon. The first time I log in with "ssh", with "Private" setup, after the password is request, results in a lock up. There is no login happening, the whole thing is just waiting for Godot. If I kill the client and re-run it, then I can login, but the funny gid=0 shows up. If "Private" is not setup, everything is quick and fine. Initially I was thinking that loading "ecryptfs.ko" was the problem, but now I think there's some strange interaction between "ssh", "pam" and "ecryptfs". I checked /var/log/secure (I can paste it later, if you need), but I could not identify anything specific. Could you please try to setup some dummy user, belonging to "ecryptfs" group, with "Private" setup, and login via "ssh"? If you can at least confirm my observation it would be a relief for me. Finally, how about the status of this report? Should be changed to something different that "ON_QA"? Thanks a lot in advance, bye, pg
I think a new bug should be created for this issue. The original problem that pam_ecryptfs was not called at all in the PAM setup of sshd is now solved. The gid=0 is indeed very strange and even a security issue. So either this sshd/pam_ecryptfs problem should be either solved fast or the postlogin call from sshd should be reverted. Please open the new bug against encryptfs and put into cc me and jchadima. Meanwhile until the issue is solved Jan, please, do not push the openssh update in F15 to stable!
(In reply to comment #11) > Meanwhile until the issue is solved Jan, please, do not push the openssh update > in F15 to stable! I second that, in fact I'd even recommend "unpush" until it's solved
Unpushed, please let me know when repush.
openssh-5.6p1-33.fc15.1 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
Hi all, the latest ecryptfs-utils (from 87-7 on) seems to fix this one, so I guess the bug can be closed, if openssh supports the automount of ~/Private. Thanks, bye, pg