Actually, I think sshd is changing the euid to the incoming user BEFORE opening the PAM session. This makes more sense because a non-priveleged user cannot change the # file descriptors above 1024, only root can. Turning UsePrivilegeSeparation off makes sshd open the PAM session as root, thus changing # file desc. before turning it over to the non-privileged user. Keep in mind this is just a best guess explanation. :-) Cheers! -Sean On Mon, 2004-09-13 at 18:27, centos-admin at caosity.org wrote: > Well, I found a workaround if not the answer. Modify > /etc/ssh/sshd_config and set 'UsePrivilegeSeparation' to no, then > restart sshd. The default for UsePrivilegeSeparation is yes. > > My guess is that, under UsePrivilegeSeparation yes, sshd is changing the > euid to the incoming user AFTER opening the PAM session - thus causing > the user to get the system defaults. Maybe somebody could provide a > better explanation than me? > > Cheers! > Sean > > On Mon, 2004-09-13 at 16:57, centos-admin at caosity.org wrote: > > Why can't non-uid 0 users have more than 1024 file descriptors when > > logging in via ssh? > > > > I'm trying to allow a user to have a hard limit of 8192 file > > descriptors(system defaults to 1024) via the following setting in > > /etc/security/limits.conf: > > jdoe hard nofile 8192 > > > > But when jdoe logs in via ssh and does 'ulimit -Hn' he gets '1024' as a > > response. If he tries to set it with 'ulimit -Hn 8192' he gets an > > 'Operation not permitted' error. If jdoe instead telnets to the box, he > > gets the hard limit of 8192 file descriptors. > > > > Here is what happens when I set the hard limit to 512 in limits.conf: > > jdoe hard nofile 512 > > > > When jdoe logs in via ssh, he gets a hard limit of 512 file > > descriptors. The same goes for telnet. So ssh is certainly reading the > > limits.conf file and applying the settings, so long as nofile <= 1024. > > > > Why won't ssh allow users to have more than 1024 file descriptors??? > > > > Many thanks! > > -Sean