Description of problem: I use LDAP to authenticate all users in my environment. In previous versions of PAM w/RH, I could have the following in my /etc/pam.d/system-auth: ession required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0 022 session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so session optional /lib/security/pam_ldap.so But in Taroon Beta 2, the pam_mkhomedir line does not work. It causes this error in /var/log/secure: Sep 24 04:58:48 elpcsm10 sshd[8931]: Accepted password for tperry from 10.130.28.231 port 4882 ssh2 Sep 24 04:58:49 elpcsm10 sshd[8933]: fatal: PAM session setup failed[6]: Permission denied Removing the pam_mkhomedir directive works. The default permissions on /home are 755. Version-Release number of selected component (if applicable): pam-0.75-51 How reproducible: Every time. Steps to Reproduce: 1. Place the above entry for pam_mkhomedir.so in the /etc/pam.d/system-auth 2. Try to login with an account that doesn't currently have a home dir. 3. Profit!! Actual results: User can't login. Error mesg thrown to log file is "fatal: PAM session setup failed[6]: Permission denied" No home directory autocreated either. Expected results: User should be able to login and a home directory should be created. Additional info:
is this with all services or just one? Does local login work? telnet? ssh? May be the app has dropped privs required to make the homedir before that part of the stack is run
SSH and FTP drop privs (apparently). Telnetting in will create a home directory. So where do we go from here? Is it a problem in PAM or in SSH and FTP? [root@elpcsm10 home]# telnet localhost Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Red Hat Enterprise Linux release 2.9.5AS (Taroon) Kernel 2.4.21-3.EL on an i686 login: brianb Password: Creating directory '/home/brianb'. Last login: Fri Sep 26 07:48:41 from localhost.localdomain [brianb@elpcsm10 brianb]$ [root@elpcsm10 home]# service vsftpd restart Shutting down vsftpd: [FAILED] Starting vsftpd for vsftpd: [ OK ] [root@elpcsm10 home]# ftp localhost Connected to localhost.localdomain. 220 (vsFTPd 1.2.0) 530 Please login with USER and PASS. 530 Please login with USER and PASS. KERBEROS_V4 rejected as an authentication type Name (localhost:root): brianb 331 Please specify the password. Password: 500 OOPS: cannot change directory:/home/brianb Login failed. 421 Service not available, remote server has closed connection ftp> quit
I am having the same problem with Fedora Test 2. For example... ssh dws77 u21305@dws77's password: Creating directory '/home/u21305'. Could not chdir to home directory /home/u21305: No such file or directory /usr/X11R6/bin/xauth: error in locking authority file /home/u21305/.Xauthority An ugly work around is to chmod 777 /home which produces the following result: ssh dws77 u21305@dws77's password: Creating directory '/home/u21305'. /usr/X11R6/bin/xauth: creating new authority file /home/u21305/.Xauthority which is the right behavior, but with an obvious security problem. From a quick look at mailing lists such as https://listman.redhat.com/archives/pam-list/2003-July/msg00007.html it appears there may be a bug in the sequence leading to the directory creation.
The work around for now is to edit sshd_config and set UsePrivilegeSeparation no After that add session required pam_mkhomedir.so skel=/etc/skel/ umask=0022 to /etc/pam.d/login and /etc/pam.d/sshd You shouldn't add anything manualy to /etc/pam.d/system-auth since running authconfig will kill your changes. And setting /home to 777 is just a little unsecure. I'm testing this on Fedora Core 1 and now everything works great so far. Apparently this will/is be fixed in ssh 3.8p1-1 or atleast that's what this thread(http://lists.debian.org/debian-ssh/2004/03/msg00032.html) lead me to believe.
Good call on the privilege seperation thing. That's the ticket! Incidentally, I always edit 'system-auth' because every other service uses it so it's a good one-stop file to edit. Either I edit every service in pam.d and add the mkhomedir line or edit system-auth once and I'm done. Which makes more sense? :-) I had bad experiences with authconfig in RHEL 2.1, so that's a moot point for me. Well that and I already have a system-auth file that works for me.
Allthough priviledge seperation is a possible workaround for users accessing the machine using ssh, it is by no means a fix. Other methods of login, such as su or ftp, both change the uid to the user and make the mkdir "/home/<user>" call with the user uid. I say this is a bug because other session modules such as pam_limits must be running with root permissions since it can set higher limits than default even with priviledge seperation on. If pam_limits is running with root permissions why shouldn't pam_mkhomedir be dong the same. Priviledge seperation is a temporary workaround for users accessing the machine with ssh, but is not the fix.
Hi All, I have been using samba, with an openldap back end storing the SID->UID/GID mappings from a windows 2003 active directory server. We use the pam_mkhomedir.so module, allowing local access through gdm and remote through ssh. I am using the "privledge seperation no" setting, to allow sshd to create a homedirectory. Sometimes however, I Get calls from users who tried using ssh or gdm, saying they cannot login, and when I check their homedirectory has been created but owned either by another user, or a UID that doesn't exist in the system. Has anyone else seen this bug? Once I chown the homedirectory to the correct UID it works fine, but still this is very annoying, and it doesn't happen every time so I am at a loss as to what is causing it... My openldap backend has the correct mappings stored for them, but somehow I think pam_mkhomedir.so is just picking random UIDs for the directory it creates.
I don't see this problem and I have PrivilegeSeparation enabled in sshd_config file. I have latest devel packages pam-0.77-56 and openssh-3.9p1-4.
Should we fix that somehow in RHEL-3? I'm afraid the problem lies in how older openssh releases implemented priviledge separation. That's the reason I don't see it on latest pam+openssh.
*** This bug has been marked as a duplicate of 135572 ***