similar to: [Bug 396] sshd orphans processes when no pty allocated

http://bugzilla.mindrot.org/show_bug.cgi?id=396 Summary: sshd orphans processes when no pty allocated Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy:

http://bugzilla.mindrot.org/show_bug.cgi?id=396 ------- Additional Comments From dtucker at zip.com.au 2002-09-12 23:26 ------- Created an attachment (id=145) --> (http://bugzilla.mindrot.org/attachment.cgi?id=145&action=view) Send HUP to sshd child procs on exit ------- 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=396 ------- Additional Comments From markus at openbsd.org 2003-06-05 00:09 ------- sending signals could be dangerous, depending on the permissions of the sending process, e.g. a root-owned sshd sending to a setuid process. but i'm not sure. we had similar code there before. ------- You are receiving this mail because: ------- You are the

http://bugzilla.mindrot.org/show_bug.cgi?id=396 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch ------- 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=396 ------- Additional Comments From djm at mindrot.org 2005-02-14 11:55 ------- Is this not another manifestation of the infamous bug #52? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

https://bugzilla.mindrot.org/show_bug.cgi?id=396 Marc Herbert <marc.herbert+mindrot at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marc.herbert+mindrot at gmail. | |com --- Comment #14

http://bugzilla.mindrot.org/show_bug.cgi?id=396 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

https://bugzilla.mindrot.org/show_bug.cgi?id=396 Martin d'Anjou <point14 at magma.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |point14 at magma.ca --- Comment #13 from Martin d'Anjou <point14 at magma.ca> 2008-12-13

https://bugzilla.mindrot.org/show_bug.cgi?id=396 Andrew McNabb <amcnabb at mcnabbs.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amcnabb at mcnabbs.org --- Comment #16 from Andrew McNabb <amcnabb at mcnabbs.org> 2012-02-10 05:21:40 EST

https://bugzilla.mindrot.org/show_bug.cgi?id=396 Tyler Riddle <triddle at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |triddle at gmail.com --- Comment #20 from Tyler Riddle <triddle at gmail.com> --- I just hit the condition of

Hello everyone, I've look at the latest nightly snapshot but I could find this bug is fixed on the source code. Is there any progression to fix that issue. This bug is open for almost 10 years, come on guys :) >List: openssh-unix-dev >Subject: Re: killing remote commands >From: HAUTREUX Matthieu <matthieu.hautreux () cea ! fr> >Date: 2010-10-21

Hello Darren, The major problem we are running into is that the shell (both sh and ksh) does not kill its child processes when there is no pty. The SSH patch mentioned previously at http://bugzilla.mindrot.org/show_bug.cgi?id=396 is not sufficient to kill the forced command completely.It will only kill the shell script, but not any child processes the shell script runs. The shell assumes the

http://bugzilla.mindrot.org/show_bug.cgi?id=585 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From dtucker at zip.com.au 2003-12-22

http://bugzilla.mindrot.org/show_bug.cgi?id=120 ------- Additional Comments From markus at openbsd.org 2002-02-19 04:29 ------- can you allocate ptys as non-root? ------- 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=375 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From dtucker at zip.com.au 2003-01-27

http://bugzilla.mindrot.org/show_bug.cgi?id=350 ------- Additional Comments From mindrot at extern.wiggy.net 2002-07-10 20:10 ------- This happens with both privsep enabled and disabled. ------- 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=994 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn|396, 859 | Status|NEW |ASSIGNED Summary|[RELENG] Bugs planned to be |[RELENG] Bugs planned to be

Works on my netbsd tinkerbox. NetBSD 5.0.2 NetBSD 5.0.2 (GENERIC) It uses rlimit. Privsep sandbox style: rlimit I also get warnings during make. fmt_scaled.c: In function 'scan_scaled': fmt_scaled.c:84: warning: array subscript has type 'char' fmt_scaled.c:111: warning: array subscript has type 'char' fmt_scaled.c:155: warning: array subscript has type 'char'

http://bugzilla.mindrot.org/show_bug.cgi?id=350 Summary: sshd leaks fd to pty for interactive sessions Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org

We recently upgraded to openss 5.8p2 from a somewhat older version. This broke openssh login to ScreenOS devices. These devices don't support PTY allocation. Apparently, ssh now reacts to PTY allocation failure by failing the login. This is a change from the previous behavior. The simple workaround is ssh -T $device. I see in the ChangeLog that some device would hang with PTY allocation