similar to: [Bug 301] In openssh 3.3 and 3.4 pam session seems be called from non-root

http://bugzilla.mindrot.org/show_bug.cgi?id=301 Summary: In openssh 3.3 and 3.4 pam session seems be called from non-root Product: Portable OpenSSH Version: -current Platform: All OS/Version: Linux Status: NEW Severity: critical Priority: P3 Component: sshd AssignedTo:

http://bugzilla.mindrot.org/show_bug.cgi?id=301 ------- Additional Comments From misiek at pld.org.pl 2002-10-16 10:14 ------- Of course this bug is not fixed even in latest 3.5 release :-( PAM really _needs_ root priviledges. Any comments? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=83 ------- Additional Comments From djm at mindrot.org 2003-03-10 15:49 ------- Created an attachment (id=247) --> (http://bugzilla.mindrot.org/attachment.cgi?id=247&action=view) Call pam_session after child fork() Hopefully this patch will allow people to gather the feedback necessary to close this bug. ------- You are receiving this

With the sshd in recent releases of OpenSSH, some Red Hat Linux systems complain about ulimit trying to raise a limit when logging in via ssh. The problem is that packages/redhat/sshd.pam doesn't do limit checking for an sshd session. The attached patch adds the pam_limits module to the sshd session, which checks for limits set in /etc/security/limits.conf. This works on Red Hat Linux 5.2

After upgrading to openssh-3.4p1, password authentication is no longer working on my system. I'm running Linux RedHat 6.2 with: kernel 2.2.20 openssh-3.4p1 openssl-0.9.6 pam-0.72-6 pwdb-0.61-0 I've tried it with and without compression, with and without priv sep, and I always get errors like this: Jun 30 19:07:48 sugarfreejazz sshd[1344]: Failed password for randy from 10.10.10.2 port

Hi, I have one question. Is someone working on restarting transfers ability in scp ? This will be nice feature especially when you want to download huge file and you will lost connection (at 90%, 600MB file as I had) :-( -- Arkadiusz Mi?kiewicz http://www.misiek.eu.org/ipv6/ PLD GNU/Linux [IPv6 enabled] http://www.pld.org.pl/

We were previously running 5.1 x86_64 and recently updated to 5.2 using yum. Under 5.1 we were having problems when running jobs using torque and the solution had been to add the following items to the files noted "* soft memlock unlimited" in /etc/security/limits.conf "session required pam_limits.so" in /etc/pam.d/{rsh,sshd} This changed the max

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=454 ------- Additional Comments From ldv@altlinux.org 2006-03-02 00:39 MET ------- Created an attachment (id=220) --> (https://bugzilla.netfilter.org/bugzilla/attachment.cgi?id=220&action=view) iptables-1.3.5-alt-link.patch Proposed patch. FC iptables package also attempts to address this issue, but their approach is worse: it

Hi, Although this is on RHEL 4 update 2 x86-64 I would like to place the question on this list. I'm trying to set up some shell limits for a user. I've added the user to /etc/security/limits.conf There is an entry in /etc/pam.d/login with pam_limits.so as well as in /etc/pam.d/sshd When I try to set ulimit -n <value> I get : cannot modify limit : Operation not permitted

http://bugzilla.mindrot.org/show_bug.cgi?id=83 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |misiek at pld.org.pl Summary|PAM limits applied |PAM limits applied |incorrectly

I'm using Dovecot 1.1.7 on CentOS 5.2. I've changed my passdb from passwd to pam, it works fine, but I've found this messages on /var/log/secure: dovecot-auth: PAM adding faulty module: /lib64/security/pam_limits.so dovecot-auth: PAM unable to dlopen(/lib64/security/pam_limits.so) dovecot-auth: PAM [error: /lib64/security/pam_limits.so: failed to map segment from shared object:

https://bugzilla.mindrot.org/show_bug.cgi?id=1829 Summary: auth-rsa.c: move auth_key_is_revoked() call from auth_rsa_verify_response() to auth_rsa_key_allowed() Product: Portable OpenSSH Version: 5.6p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component:

I just spent some time trying to figure out how to get OpenSSH to work correctly with NIS and PAM. It seems to work fine, apart from one minor worry I still have (see below). Feedback about grave security risks are welcome :) This is using RedHat 6.1 with updates and the OpenSSH 1.2.2p1-1 RPM's on the NIS server as well as the client. In short, my configuration is: /etc/nssswitch.conf:

Hi all, I am trying to stream for over 1k users on Ubuntu 16.04. I notice that when stream connection is over 1024, it get warning like this: WARN connection/_accept_connection accept() failed with error 24: Too many open files Tried these configs and reboot, it won't work! /etc/pam.d/common-session session required pam_limits.so /etc/sysctl.conf fs.file-max = 100000

On 20 Sep 2016, at 3:10, Chen Wei Hsu wrote: > Hi all, > > I am trying to stream for over 1k users on Ubuntu 16.04. I notice that > when > stream connection is over 1024, it get warning like this: > > WARN connection/_accept_connection accept() failed with error 24: Too > many > open files > > Tried these configs and reboot, it won't work! >

It all looks like a workarounds. I would suggest using a proper solution, such as systemd, that is present in ubuntu 16.04 by default, and where you can raise system limits per system service just by tweaking its config file. m. On 8 października 2016 at 11:37:59, Chen Wei Hsu (cwhsu1984 at gmail.com) wrote: Hi all, I am trying to stream for over 1k users on Ubuntu 16.04. I notice that when

Hi, Does anybody know why openssh (openssh-2.9p1) on a linux system does not call pam_open_session if no pty is used? In this way the session modules (in /etc/pam.d) are not activated. This is especially annoying if you use pam_limits.so to set rlimits. Every user could circumvent them easily. I do not know if this issue has been discussed before and if this behavior is not alright ..... cu

On Tue, Jun 19, 2001 at 03:11:02AM +0200, Christian Kraemer wrote: > This is espacially anoying if you > use pam_limits.so to set rlimits. Every user could > cirrcumvent them easily by calling ssh in this way: > ssh user at server /bin/sh Interestingly, Debian 2.2's openssh (1:1.2.3-9.3) does enforce rlimits somehow, not sure if it was specifically patched to do this or perhaps

https://bugzilla.mindrot.org/show_bug.cgi?id=2236 Bug ID: 2236 Summary: ssh-agent: fix unintended UNIX-domain socket removal Product: Portable OpenSSH Version: 6.6p1 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: ssh-agent Assignee: unassigned-bugs

http://bugzilla.mindrot.org/show_bug.cgi?id=354 ------- Additional Comments From cjwatson at debian.org 2003-01-03 02:42 ------- Alternatively, perhaps sshd could be configured to setrlimit() everything up to RLIM_INFINITY after forking but before giving up root privileges. It could then rely on pam_limits to set limits back down if the administrator wants that, which would work even with