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));