similar to: [Bug 529] sshd doesn't work correctly after SIGHUP

Displaying 20 results from an estimated 4000 matches similar to: "[Bug 529] sshd doesn't work correctly after SIGHUP"

2003 Apr 02
0
[Bug 529] sshd doesn't work correctly after SIGHUP
http://bugzilla.mindrot.org/show_bug.cgi?id=529 Summary: sshd doesn't work correctly after SIGHUP Product: Portable OpenSSH Version: 3.6p1 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy:
2003 May 15
2
[Bug 529] sshd doesn't work correctly after SIGHUP
http://bugzilla.mindrot.org/show_bug.cgi?id=529 ------- Additional Comments From djm at mindrot.org 2003-05-15 19:00 ------- Please attach the patch to the bug, rather than pasting it in the comments field. Patches in comments are a PITA to extract. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
2011 Feb 07
1
[PATCH] ssh: set proctitle for mux master
Preserving the command line from the invoking ssh command doesn't make much sense, so use setproctitle() to hide the arguments. --- ssh.c | 20 +++++++++++++++++--- 1 files changed, 17 insertions(+), 3 deletions(-) diff --git a/ssh.c b/ssh.c index d32ef78..8ebcc88 100644 --- a/ssh.c +++ b/ssh.c @@ -230,12 +230,25 @@ main(int ac, char **av) struct servent *sp; Forward fwd; - /* Ensure
2002 Oct 11
2
Why openssh newer than 2.9.9 doesn't send SIGTERM and SIGHUP to child process?
Hi, I search in archive list if there any reason why is removed in openssh newer than 2.9.9 from function 'void session_close_by_channel(int id, void *arg)' sending of SIGTEMR and SIGHUP signals to child as was in 2.9.9 version? See follow sniped code from 2.9.9 sources: ---- openssh-2.9.9/session.c ---------------------------------------- void session_close_by_channel(int id, void
2003 Jan 19
1
OpenSSH build failure on NetBSD 1.5.2
Hi All. The recent setproctitle changes don't seem to work on NetBSD. Some of the variables are still used when the definitions are #ifdef'ed out. Attached patch fixes it, but I'm not sure it does it the right way. -Daz. gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I../../openbsd-compat -I../../openbsd-compat/.. -DHAVE_CONFIG_H -c
2011 Mar 28
15
[Bug 1883] New: use setproctitle for persistent mux master
https://bugzilla.mindrot.org/show_bug.cgi?id=1883 Summary: use setproctitle for persistent mux master Product: Portable OpenSSH Version: 5.8p1 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: unassigned-bugs at mindrot.org ReportedBy:
2003 Sep 16
1
SIGHUP fails to restart (3.6.1p2 -> 3.7p1)
I have the sshd daemon located at /sbin/ssh_22 in this scenario (because I have more than one daemon with separate executable images). After upgrading from 3.6.1p2 to 3.7p1, with the /sbin/ssh_22 copy replaced by mv (not by writing over the existing image), I do SIGHUP and get this message logged: Sep 16 15:07:36 vega sshd_22[22552]: Received SIGHUP; restarting. Sep 16 15:07:36 vega
2007 Jan 25
0
sshd unhandled SIGALRM
sshd will die from an unhandled SIGALRM if you allow SSH1 connections, ssh in, HUP sshd, and don't ssh in again for KeyRegenerationInterval. The HUP handler calls exec which resets signal handlers but persists alarm timers. Chapter and verse: http://www.opengroup.org/onlinepubs/000095399/functions/alarm.html -- Andrew Gaul http://gaul.org/ -------------- next part -------------- Index:
2007 Feb 21
0
sshd unhandled SIGALRM (resend)
sshd will die from an unhandled SIGALRM if you allow SSH1 connections, ssh in, HUP sshd, and don't ssh in again for KeyRegenerationInterval. The HUP handler calls exec which resets signal handlers but persists alarm timers. Chapter and verse:
2003 Sep 22
1
[Bug 698] fixed bug in calling pam_setcred
http://bugzilla.mindrot.org/show_bug.cgi?id=698 Summary: fixed bug in calling pam_setcred Product: Portable OpenSSH Version: 3.7.1p1 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: PAM support AssignedTo: openssh-bugs at mindrot.org ReportedBy: postadal
2001 Feb 19
0
Restarting with kill -HUP
Hi, If sshd is started with 'sshd', restarting with kill -HUP will fail. I've included the most obvious patch, but making sure that the full pathname is in saved_argv[0] just might be more secure. Cheers, Han Holl --- sshd.c.orig Mon Feb 19 10:55:54 2001 +++ sshd.c Mon Feb 19 10:56:15 2001 @@ -208,7 +208,7 @@ { log("Received SIGHUP; restarting.");
2009 Feb 25
2
miss handling of the SIGHUP signal for sshd when sshd is started with a relative path sshd_config file
Hi I am just porting ssh-5.2 to my HPUX system. but while I'm doing it, I accidently found a different handling of the sshd for the SIGHUP signal when it is started with a "./sshd_config" and "/sshd_config". The problem is as following: root at sshpa6# uname -a HP-UX sshpa6 B.11.31 U 9000/800 2404418693 unlimited-user license root at sshpa6#
2006 May 04
2
xmalloc(foo*bar) -> xcalloc(foo, bar) for Portable
Hi All. While wandering in auth-pam.c I noticed that there's a few Portable-specific escapees from the xmalloc(foo * bar) cleanup. There's also a "probably can't happen" integer overflow in ssh-rand-helper.c with the memset: num_cmds = 64; - entcmd = xmalloc(num_cmds * sizeof(entropy_cmd_t)); + entcmd = xcalloc(num_cmds, sizeof(entropy_cmd_t));
2005 Jan 12
1
sshd runs with -R flag?
Hi All, Sorry to interrupt, but I recently downloaded and installed a pre-compiled package of OpenSSH 3.9p1 for Solaris. After installation everything seems to work well, but I notice that all of the child sshd daemons are running with a flag '-R' i.e. sh-3.00# ps -ef | grep sshd root 475 1 0 13:45:23 ? 0:00 /usr/local/sbin/sshd -4 root 643 475 0 14:10:55 ?
2000 Oct 15
1
Patch for Digital Unix SIA authentication
A while back, I sent in a patch that added Digital Unix SIA authentication to OpenSSH. Well, I just figured out that it didn't handle everything correctly (locked accounts could still log in). I thought I had checked that, but I guess I missed it. Anyway, here is a patch against OpenSSH 2.2.0p1 that fixes this. -- Chris Adams <cmadams at hiwaay.net> Systems and Network Administrator
2003 May 28
2
[PATCH] sshd unable to restart
An embedded message was scrubbed... From: Tor.Egge at cvsup.no.freebsd.org Subject: sshd unable to restart Date: Sun, 25 May 2003 18:19:08 GMT Size: 2853 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030528/47273c0e/attachment.mht
2000 Oct 07
0
OpenSSH changes for BSD/OS
The following are patches against openssh 2.1.1p4 to add support for the BSD_AUTH authentication mechanisms. It allows the use of non-challenge/response style mechanisms (which styles are allowed my be limited by appropriate auth-ssh entries in login.conf). The patches also add support for calling setusercontext for the appropriate class when called with a command (so that the PATH, limits,
2001 Dec 19
0
Patch for DU SIA auth
Hello. The following is a patch against OpenSSH 3.0.2p1 to fix OpenSSH's handling of Tru64 SIA authentication. The main changes are to make the SIAENTITY a global variable (so that it remains persistent across function calls), initialization only happens once, the session is only released once. This makes SIA modules that require authentication in order to perform certain actions during the
2003 Feb 27
0
Update for Tru64 Unix
Here is a long-overdue (sorry about that) patch for Tru64. It is pretty minor mostly (minor formatting and removal of a couple of unneeded calls), and it disables post-auth privsep (so that OpenSSH will work "out of the box" on Tru64, avoiding the many questions). I'm also looking at getting setproctitle working. For Tru64 4.x, it isn't a big deal (normal PS_USE_CLOBBER_ARGV
2010 Jan 05
7
[Bug 1692] New: sshd sometimes dies when sent multiple SIGHUPs in quick succession
https://bugzilla.mindrot.org/show_bug.cgi?id=1692 Summary: sshd sometimes dies when sent multiple SIGHUPs in quick succession Product: Portable OpenSSH Version: 5.3p1 Platform: Other URL: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug /497781 OS/Version: Linux Status: NEW