When I enter
@extern hard nproc 20
into /etc/security/limits.conf then openssh doesn't allow anybody from
group extern to log in remotely through ssh.
(SYSLOG: sshd: Disconnecting: fork failed: Resource temporarily
Other limits work well.
$ rpm -q pam openssh ; uname -a
Linux xxxxxxxxxxx.mff.cuni.cz 2.4.1 #2 Wed Jan 31 13:14:29 CET 2001 i586
(BTW - same with up-to-date RH7.0 with Linux 2.4.x)
We (Red Hat) should really fix this before the next release.
Please check if openssh-2.3.0p1-16 in http://people.redhat.com/nalin/test/ fixes
this for you.
No, this time it looks like it's ignoring /etc/security/limits.conf ...
User is allowed to log in but user can fork more processes than he is limited to.
maxlogins are also ignored (they're set to 4, but user is allowed to log in 6
times and more ...) priority is also ignored.
auth required /lib/security/pam_stack.so service=system-auth
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_limits.so
session optional /lib/security/pam_console.so
ftp hard nproc 0
@extern - maxlogins 4
@extern hard nproc 20
@extern hard rss 40000
@extern hard priority 5
guest hard priority 10
I hope there is nothing special to "turn on" in kernel (I've got my own
2.4.2-pre2) or in sshd_config ... It worked before...
Ah, now I see. There was some weirdness in how pam_limits handled group limits
on maximum logins (specifically, it didn't work). Please try pam-0.74-8 in
http://people.redhat.com/nalin/test/, which should fix this. Other items
(nprocs and friends) should already be working correctly with
Does not work :( limits seemes to be ignored. User guest is allowed to log in
10-times and more and he can fork 60 and more processes. (same setup as above
with "guest" in group "extern" of course).
# rpm -q pam openssh ; uname -r
The system is upgraded to current Rawhide.
Are you sure the user is in that group? Is 'guest' listed when you run 'getent
[martin@sarah:~]% ssh -l guest -p 2222 localhost [11:37]
Last login: Wed Feb 14 11:37:03 2001 from localhost
You have mail.
[guest@sarah guest]$ id ; grep extern /etc/group ; getent group extern
uid=600(guest) gid=100(users) groups=100(users),603(extern)
<here I try to recursively or remotely repeat login to override maxlogins,
recursively run 60 shells ... with success> (see to /etc/pam.d/sshd &
If you need more info about configuration etc. ... just ask.
Try adding "debug" to the list of flags at the end of the pam_limits lines in
/etc/pam.d/ssh and /etc/pam.d/system-auth, the line "*.debug /var/log/debug" to
/etc/syslog.conf, and restarting both syslogd and sshd using their init scripts.
When you then attempt to log in, messages like these (along with others) should
be logged to /var/log/debug:
Feb 14 11:11:15 blade pam_limits: reading settings from
Feb 14 11:11:15 blade pam_limits: process_limit: processing(1) - maxlogins
Feb 14 11:11:15 blade pam_limits: checking logins for 'nalin' / 4
Feb 14 11:11:15 blade pam_limits: Too many logins (max 4) for nalin
If the limit you're setting is not shown being processed, then for whatever
reason, pam_limits has determined that the limit doesn't apply to the user who's
logging in. If you don't see any of these, then it's likely that pam_limits
isn't being called (which is not happening on my test setup here).
Noo :(( look:
[root@ /etc/pam.d]# grep limit *
sshd:session required /lib/security/pam_limits.so debug
system-auth:session required /lib/security/pam_limits.so debug
[root@ /etc]# grep debug syslog.conf
[root@ /var/log]# grep limit debug
[root@ /var/log]# tail debug
Feb 14 23:40:21 sarah sshd: Server listening on 0.0.0.0 port 2222.
Feb 14 23:40:21 sarah sshd: Generating 768 bit RSA key.
Feb 14 23:40:24 saFeb 14 23:40:59 sarah sshd: Accepted password for guest from 127.0.0.1 port 2298 ssh2
Feb 14 23:41:02 sarah sshd(pam_unix): session closed for user guest
[root@ /etc]# rpm -q pam openssh ; uname -r
:( Any suggestions? May I send somewhere "rpm -qa" or some other configuration? (The system is uptodate Rawhide ...)
Can the problem be somewhere else? Probably not because when I use pam/openssh from Rawhide, limits work well (except for nfork), with these versions it look like it's ignored ...
Yes, please attach the output of "rpm -qa | sort". I'm baffled by this
problem. There might be some clue there.
Created attachment 10080 [details]
"rpm -qa|sort" output
Um, that list includes pam-0.74-5 and openssh-2.3.0p1-14. I'm assuming that's
that list of packages on the client, right? The bugs are on the server end of
the connection, so I'd need that list.
*** Bug 27692 has been marked as a duplicate of this bug. ***
No, this is the server and these are the versions which now work for me (except
nfork that was the reason I reported this). When I did the tests, I always
downloaded and used the versions you told me to: (like this)
$ wget ... # download you versions
$ rpm --rebuild pam... openssh... # rebuild them
$ rpm -Uvh pam* openssh* # upgrade to these new versions
$ <vi /etc/pam.d/... /etc/syslogd.conf .. ; restart sshd $ syslogd>
# add "debug" as you told me to
$ <do the test if limits work - NO> # test if limits work - DOESNT :(
$ <report unsuccesfull tests> # fill up bugzilla
$ rpm -Uvh openssh* pam* --oldpackage # downgrade back versions from Rawhide
So the "rpm -qa|sort" was the list on server (with rawhide's rpm's of
pam/openssh). When I did the tests I reported I ALWAYS USED YOUR VERSIONS of
openssh/pam (on the same machine - both client and server).
With openssh-2.5.1p1-2 and pam-0.74-12 (from rawhide) on release 7.0.91 (Wolverine) resource limits now work ok (fork, memory, priority ..) except for
@extern - maxlogins 4
but users from group extern are allowed to log more then 4 times ...
... and with newer rawhide's packages (openssh-2.5.1p1-7, pam-0.74-13) fork resource limits doesn't work (Disconnecting: fork failed: Resource temporarily
unavailable) and MaxLogins doesn't work (user from group @extern is allowed to login more times). Other limits (memory) seemes to work (according to "ulimit -a").
This is something of an architectural limitation. I've been mulling over how
this could be fixed for a while now, but the crux of the problem is that sshd
opens the PAM session before it drops privileges (it has to, for modules like
pam_lastlog to work at all). This causes the nproc limit to be affected by the
number of processes being run by the superuser (which is probably most of them),
so sshd is immediately unable to fork() off a child process to provide the login
session, and the whole thing fails. That leaves the addition of a separate
limits processing stage to sshd's child process as the only viable solution, but
that may have to wait for another release.
JFYI: the problem was not fixed in RH7.1 yet ... is it going to be in updates
someday? do you plan it?
Fixed in releases using pam-0.77.