similar to: ssh exit mechanism!

do_pre_login() in session.c is used (in do_exec_pty()) before it's declared, which is causing some problems for me. please move it up a couple hundred lines in the file. patch included for 0807 snapshot. thanks, wendy % diff -u session.c.orig session.c.mod --- session.c.orig Tue Aug 7 13:11:51 2001 +++ session.c.mod Tue Aug 7 16:21:07 2001 @@ -397,6 +397,34 @@ } }

Please review the function below, forkoff(), meant to be used in clientloop.c instead of daemon() and the code in process_escapes(). The intention is to make ~D ( like ~& but also detach) possible and to make it possible for ssh -f (or ssh -f -f - see other thread on this) to detach, not just forkoff(). I also intend to use the same detach technique in a feature patch for the hang-on-exit

My port forwarding changes require an authorization (authentication) context in channel_connect_to(). I'd like to change the dispatch_* functions so that they accept an Authctxt * instead of a void * (this parameter is already used this way). In addition, I'd have to pass the authctxt all the way down to channel_connect_to(). As a side effect, it's possible to get rid of the global

On Tue, 21 May 2024, Opty wrote: > Hello, > > can anyone confirm that OpenSSH server doesn't log client disconnect > without SSH_MSG_DISCONNECT? OpenSSH logs the disconnection regardless of whether the client sends SSH_MSG_DISCONNECT or just drops the connection. A little more information may be logged from the disconnect packet if it was sent, but there should always be a

When connecting with v1, the server logs a message when I exit my login shell: Closing connection to 130.207.167.32 However, when connecting with v2, it only ever logs: Connection closed by remote host. Tracing through the code, it appears that instead of breaking in serverloop.c:server_loop2() at: if (had_channel && !channel_still_open()) {

Hello, can anyone confirm that OpenSSH server doesn't log client disconnect without SSH_MSG_DISCONNECT? PuTTY stopped sending it long time ago [1] and I wonder if any client must or at least should do that like OpenSSH client does. I have disabled e-mail delivery so Cc me please. Regards, Opty ---------- [1]

On Wed, May 22, 2024 at 6:29?AM Damien Miller <djm at mindrot.org> wrote: > OpenSSH logs the disconnection regardless of whether the client sends > SSH_MSG_DISCONNECT or just drops the connection. > > A little more information may be logged from the disconnect packet > if it was sent, but there should always be a "Connection closed by ..." > message regardless. I

Background ========== "ssh -f ..." causes ssh to fork into the background when userauth successfully completes. WHAT === With this patch "ssh -f -f ..." causes ssh to fork into the background when the first forwarded port/x11 display/agent is successfully opened. WHY === This feature makes launching remote X11 apps more reliable: when ssh exits it must have exited because

Markus, How's this patch? - a chan_wont_read()/chan_wont_write() API is added that is very much like chan_read_failed()/chan_write_failed(), but for the debug messages and chan_wont_*() don't ever call error() The 3.0.2p1 channel_pre_x11_open() uses chan_*_failed() but looks like it ought to use chan_wont_*() instead :) - forkoff() no longer fakes EOF for SSHv2 (still

Yes, this is a patch against an older version of OpenSSH with other stuff anyways, BUT, it's so TRIVIAL(*), that you can see how it would apply to newer versions (which I've not tried). Here's the gist: server_loop2() has a race condition with respect to reception of SIGCHLD and checking/setting child_terminated. This patch does two things: wait_until_can_do_something() adds a 1

I'd like a feature whereby ssh puts itself in the background after the first successful X11 (or other port) forwarding. The reason for this is simple: error handling. If the application fails to open the X display and exits, then the client can still exit with the application's exit code. But if the application opens the X display successfully, then it can just display any errors by

To whomsoever it may concern, I have compiled openssh-2.9p2 in LynxOS and it works fine. But there is one problem. The ssh client program hangs on exit. I run the sshd server in LynxOS and connect from a ssh client in Linux system. This is the debug output that I get: < sshd running in LynxOS on i386 machine> # ./sshd -d debug1: Seeding random number generator debug1: sshd version

I am testing with a 5.4p1 client and have noticed, on the server side, that sometimes an SSH_MSG_DISCONNECT message is received with the following 28-byte long payload: 0x00 0x00 0x00 0x0b Reason: SSH_DISCONNECT_BY_APPLICATION 0x00 0x00 0x00 0x14 Description string length: 20 bytes 0x64 0x69 0x73 0x63 0x6f 0x6e 0x6e 0x65

http://bugzilla.mindrot.org/show_bug.cgi?id=1307 Summary: client disconnects if ServerAlive enabled but not implemented Product: Portable OpenSSH Version: 4.3p2 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: bitbucket at

https://bugzilla.mindrot.org/show_bug.cgi?id=1750 Summary: Sftp hangs if stderr is used. Product: Portable OpenSSH Version: 5.4p1 Platform: Other OS/Version: All Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: unassigned-bugs at mindrot.org ReportedBy: jchadima at

Using the latest snapshot, I'm still getting periodic ssh sessions hanging after they've completed. It used to be very common, but the prior fixes reduced the frequency to about one hung per day (out of thousands). These don't timeout at any point, they'll hang around for days if not killed manually (blocking the scripts from continuing). The commands ssh is hanging on are nothing

openssh-2.9.9p2 assumes that pid_t, uid_t, gid_t, and mode_t are no wider than int. GCC complains about this assumption on 32-bit Solaris 8 sparc, where these types are 'long', not 'int'. This isn't an actual problem at runtime on this host, as long and int are the same width, but it is a problem on other hosts where pid_t is wider than int. E.g., I've heard that 64-bit

Every once in a while, my terminal session with an OpenSSH server (any version, up to and including 2.9p2) will hang indefinitely upon logout, rather than returning to the shell on my UNIX client machine (or closing the window, if in a M$ environment). Unfortunately, I can't reproduce the problem, but it does occur frequently enough to be annoying. When it does happen, this is what I see on

on FreeBSD, gcc complains that %d is used for sig_atomic_t Casting to (int) as a solution ? Index: serverloop.c =================================================================== RCS file: /cvs/openssh/serverloop.c,v retrieving revision 1.172 diff -u -p -r1.172 serverloop.c --- serverloop.c 2 Dec 2012 22:50:55 -0000 1.172 +++ serverloop.c 4 Dec 2012 11:46:33 -0000 @@ -708,7 +708,7 @@

using openssh-3.8.1p1 from sunfreeware.com on a SunOS XXX 5.8 Generic_117000-03 sun4u sparc SUNW,Sun-Fire-V240. sshd seems to ignore or miss SIGCLD. this is a rare behaviour we observe about once per week in a ssh intensive environment. the process hangs here: truss: 24453: poll(0xFFBEEF28, 2, -1) (sleeping...) gcore, mdb: libc.so.1`_poll+4(b, 0, 0, ffbeef38, 6fc40,