similar to: sshd unhandled SIGALRM

Displaying 20 results from an estimated 1000 matches similar to: "sshd unhandled SIGALRM"

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 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 Mar 06
0
sshd Termination by SIGALRM
Hi, I am seeing a problem where in sshd gets terminated by SIGALRM. sshd was listening on the socket and was not restarted. I saw a recent bug fix in openBSD openssh CVS which mentions: Clear alarm() before restarting sshd on SIGHUP. Without this, if there's a SIGALRM pending (for SSH1 key regeneration) when sshd is SIGHUP'ed, the newly exec'ed sshd will get the SIGALRM and
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.");
2014 May 02
0
[PATCH] 'ssh -A' / 'ssh-add -c' crossref
Hello, The documentation of 'ssh -A' does not mention that the risks can be somewhat mitigated by using the '-c' option of 'ssh-add'. In my experience, people are unaware of the '-c' option, so I suggest to point to it from the documentation of '-A': Index: ssh.1 =================================================================== RCS file:
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:
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
2024 Oct 15
1
[Bug 3744] New: openssh-SNAP-20241015 sshd-auth.c:467:2: error: use of undeclared identifier 'saved_argc'; did you mean 'saved_argv'?
https://bugzilla.mindrot.org/show_bug.cgi?id=3744 Bug ID: 3744 Summary: openssh-SNAP-20241015 sshd-auth.c:467:2: error: use of undeclared identifier 'saved_argc'; did you mean 'saved_argv'? Product: Portable OpenSSH Version: 9.9p1 Hardware: ARM64 OS: Mac OS X
2005 Dec 23
4
sshd blocks SIGALRM
Gidday everbody, We have just found an interesting issue regarding the sshd daemon on our SuSE system. For some reasons, the /usr/sbin/sshd process blocks SIGALRM as shown in the /proc/pid/status: $ cat /proc/`cat /var/run/sshd.init.pid`/status Name: sshd State: S (sleeping) SleepAVG: 0% [...] SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000002000 <-- SIGALRM is
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
2004 Sep 24
0
[LLVMdev] SlowOperationInformer.cpp:55: error: `SIGALRM' undeclared (first use this functi
Henrik Bach wrote: > Hi > > I'm compiling: /usr/local/src/llvm/lib/Support/SlowOperationInformer.cpp > on MinGW. However, it stops complaining about that SIGALRM is undeclared: Is there an alarm() syscall on MinGW? And if so, what signal does it send (according to the MinGW docs)? -- John T. > -------------------------- > @ /usr/local/build/llvm/mklib
2004 Sep 24
2
[LLVMdev] SlowOperationInformer.cpp:55: error: `SIGALRM' undeclared (first use this functi
Hi I'm compiling: /usr/local/src/llvm/lib/Support/SlowOperationInformer.cpp on MinGW. However, it stops complaining about that SIGALRM is undeclared: -------------------------- @ /usr/local/build/llvm/mklib --tag=disable-shared --silent --tag=CXX --mode=compile g++ -c -I/usr/local/build/llvm/lib/Support -I/usr/local/src/llvm/lib/Support -I/usr/local/build/llvm/include
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
2004 Sep 24
0
[LLVMdev] SlowOperationInformer.cpp:55: error:`SIGALRM' undeclared (first use this functi
>From: Reid Spencer <reid at x10sys.com> >Date: Fri, 24 Sep 2004 13:03:44 -0700 > >I just discovered that the *only* place this is used is in the debugger >when it is loading files, etc. There should be a way to do this without an >alarm. In fact, a thread could easily set the "ShouldShowStatus" every >second until the the thing is cancelled. Since the
2003 Aug 05
0
dll wrapper strategy help
I hope this is right list for this question but here is my requirement.. Develop a new Unix shared library (I'll settle for an application if it is easier) which makes calls to a vendor supplied windows DLL. On first examination it looks like winelib is the way to go, but I'm having trouble dissecting the documentation from whole windows application porting to just what I need.
2004 Sep 24
0
[LLVMdev] SlowOperationInformer.cpp:55: error: `SIGALRM' undeclared (first use this functi
There's simply no equivalent to signals on Windows. There is no way to asynchronously interrupt a thread's processing to execute some handler. The only thing you can asynchronously do to a thread is kill it, and that's generally frowned upon (who knows what critical sections it might be holding, etc...). Stuff like alarms is supposed to be done using the "event-driven"
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
2004 Sep 24
2
[LLVMdev] SlowOperationInformer.cpp:55: error: `SIGALRM' undeclared (first use this functi
Ultimately, this is another function that needs to go into lib/System. An alternate approach is to fork a thread, sleep, and when the thread wakes up, "ring the alarm". Reid. John Criswell wrote: > Henrik Bach wrote: > >> Hi >> >> I'm compiling: >> /usr/local/src/llvm/lib/Support/SlowOperationInformer.cpp on MinGW. >> However, it stops
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));