On Fri, Aug 15, 2003 at 12:22:50AM +0200, Werner Schalk wrote: > Aug 14 16:09:23 susi pam_chroot[2721]: session: reading config file > (/etc/security/chroot.conf) > Aug 14 16:09:23 susi pam_chroot[2721]: session: found chroot_dir > "/home/pmuster" for user "pmuster" > Aug 14 16:09:23 susi pam_chroot[2721]: session: chroot(/home/pmuster): > Operation not permitted > Aug 14 16:09:23 susi pam_chroot[2721]: session: returning failure > Aug 14 16:09:23 susi sshd[2721]: fatal: PAM session setup failed[14]: Cannot > make/remove an entry for the specified session > > Any ideas what might cause this? Actually I have created a basic file system > for that user and a "su - pmuster" works fine (no chrooted environment > then!). Any hints? As Nalin said, the problem indicated by your logs is that at the time chroot(...) is called, you are not root, and so the chroot(...) fails. You have a few options for getting the job done at this point, none of which are perfect. 1. Put 'UsePrivilegeSeparation no' in sshd_config. Note that if you do this, sshd will run a lot more code as root than it would otherwise, which increases your exposure to bugs by some undefined amount. 2. Make your shell a setuid wrapper which chroots, does setgid/setuid, and then execs whatever shell you really want to run. This is kind of messy and since it involves replacing your shell, it would affect all your logins, not just the ssh ones. I tend to think that the first option is the cleaner one, but obviously, you might see that route as not being secure/paranoid enough. I think there are enough opportunites to screw up the second method to offset the possible risk of turning off privlege seperation. -- Ed Schmollinger - schmolli@xxxxxxxxxxxxxx
Attachment:
pgp00100.pgp
Description: PGP signature
