#84300 ssh: OpenSSH 2.3.0p1-1.11 requires 33 processes/user to open session

Package:
ssh
Source:
openssh
Submitter:
Marek Habersack
Date:
2005-07-18 03:07:00 UTC
Severity:
normal
#84300#5
Date:
2001-01-31 18:47:57 UTC
From:
To:
If the nproc rlimit is set to <33 then the sshd will fail to open the user
session after successful authentication with the "fork failed: resource
temporarily unavailable" error message.
--- Ignoring conffile /etc/ssh/sshd_config (not world readable)

--- Begin /etc/ssh/ssh_config (modified conffile)
Host localhost
    ForwardAgent yes
    ForwardX11 yes
   ForwardAgent no
   ForwardX11 no
   RhostsAuthentication no
   RhostsRSAAuthentication no
   RSAAuthentication yes
   PasswordAuthentication yes
   FallBackToRsh no
   UseRsh no
   BatchMode no
   CheckHostIP yes
   StrictHostKeyChecking no
   IdentityFile ~/.ssh/identity
   Port 22
   Protocol 2,1
   Cipher 3des
   EscapeChar ~



--- End /etc/ssh/ssh_config



--- Begin /etc/pam.d/ssh (modified conffile)
auth       required     pam_nologin.so
auth       required     pam_unix.so
auth       required     pam_env.so # [1]
account    required     pam_unix.so
session    required     pam_unix.so
session    optional     pam_lastlog.so # [1]
session    optional     pam_motd.so # [1]
session    optional     pam_mail.so standard # [1]
password   required     pam_unix.so
session    required   	  pam_limits.so
--- End /etc/pam.d/ssh
#84300#10
Date:
2001-09-05 21:34:02 UTC
From:
To:
Just some extra info about this bug.  It appears to be an upstream problem.

----- Forwarded message from Nalin Dahyabhai <nalin@redhat.com> -----

From: Nalin Dahyabhai <nalin@redhat.com>
To: Ognyan Kulev <ogi@fmi.uni-sofia.bg>
Cc: openssh-unix-dev@mindrot.org
Subject: Re: pam_limits and OpenSSH
X-Random-Fortune: I always have fun because I'm out of my mind!!!
Organization: Red Hat, Inc.
X-Department: OS Development
X-Key-ID: 2537B551
X-Key-Fingerprint: 44D4 B47B 392A 7A64 1D72  08E2 236F 3E15 2537 B551

This is exactly the case.  The process limit is set while the server
is still running as the superuser, so it can't fork() to start the
child (which would then do a setuid() to the user's ID).

Opening the PAM session after performing the fork() and setuid() fixes
this for pam_limits, but breaks other modules which expect to be running
with superuser privileges when their pam_open_session() handlers are
called.  This was the crux of the whole pam_open_session mess from a few
months ago -- my apologies for setting it in motion.

Other process limits are going to have similar effects on sshd, and I
don't see a clean way to handle process limits within PAM in this case.

Hope this cleared things up a bit,

Nalin



----- End forwarded message -----
#84300#17
Date:
2002-01-18 20:32:54 UTC
From:
To:
Hi,

I just thought I'd add this comment to make it clear how grave the problem
is.

On a busy computer with many processes running as root (e.g. due to service
monitoring software like daemontools), the required process limit for users
to be able to log in can be arbitrarily high; I currently need about 650,
which kind of beats the purpose of the process limit. If it weren't for this
ssh/PAM bug, I'd be able to get away with about 30 processes per user.

For now, I'll probably work around the problem by removing pam_limits from
/etc/pam.d/ssh, and setting up resource limits from shell startup scripts,
but this is no solution.

Regards,

Andrew