similar to: [PATCH] Added Null packet keepalive option

Hi! The following patch adds ability to configure the ssh client to send SSH[2]_MSG_IGNORE packets of random length at random times whithin a user-specified interval. The function is configured by setting the config-file options BogusTrafficIntervalMax and BogusTrafficIntervalMin, which defines the interval in seconds in which the packets are randomly sent. It is disabled by default. It suffices

Hi, The firewall at work doesn't allow me to make a direct SSH connection to the Internet, so I use the ProxyCommand to tunnel SSH through a HTTP proxy. This works fine, except for the fact that the HTTP proxy server closes the connection after 60 seconds of inactivity. Attached below is a patch that implements a new configuration option called "Idle" that lets you specify the

Here is a patch to implement a handy new feature proposed by John Hardin <johnh at aproposretail.com>. This is his description of the feature: New option for OpenSSH: Delay before exit. Command line option: -S delay Config file option: sleep {delay} Purpose: Wait the specified number of seconds after last traffic before dropping the connection and exiting. If ports are forwarded, this

Here is a patch to implement an exit delay in OpenSSH-3.0.2p1, proposed by John Hardin. This is his description of the feature: New option for OpenSSH: Delay before exit. Command line option: -S delay Config file option: sleep {delay} Purpose: Wait the specified number of seconds after last traffic before dropping the connection and exiting. If ports are forwarded, this causes the ssh client

As you are now probably aware, the portability team for openssh still has not fixed the hang-on-exit bug in the 2.9.9p2 release. Attached is a patch for 2.9.9p2 that fixes the hang-on-exit bug for Linux systems. It also adds a useful exit delay feature that has also not yet been incorporated into the main sources. For more information, see the SNFS (secure NFS) web page:

Hello all, This is a problem and patch reported to Red Hat Bugzilla by Jonathan Kamens <jik at kamens.brookline.ma.us>. I'm just acting as a relay :-) jik has experienced some weird crashes relating to window size changes or some similar activity. These are rather hard to trace. Problem was fixed by patching clientloop, where fd_set structures appear to be improperly zeroed (bytes vs

The hang-on-exit bug still hasn't been fixed in OpenSSH-3.0p1... :-( Here again is the patch to fix this bug under Linux, updated for OpenSSH-3.0p1. This has been exhaustively tested for six months now. It also add an exit delay option that can be useful. The patch does not lead to data loss under Linux. Please see the Secure NFS page (SNFS) for further details:

Here is my third attempt at the idletimeout patch. I tried to address the points which Marcus Friedl brought up. It is actually bigger than the previous patches, but not as intrusive. It is big because it moves some stuff from serverloop.c to packet.c. - I moved all the logic to packet.c. This means that I also had to move the actual select() call, which used to be in serverloop.c to packet.c.

Greetings, I have a problem with OpenSSH -current and SCO 3.2v4.2, when I execute a remote command or exit from a session, the connection hangs, ( line 326 of serverloop.c). This problem only exists when using ssh2. server side debug (-d -d -d ): debug1: Received SIGCHLD. debug2: channel 0: read failed debug2: channel 0: close_read debug2: channel 0: input open -> drain debug2: channel 0:

http://bugzilla.mindrot.org/show_bug.cgi?id=651 Summary: SCO 3.2v4.2 and OpenSSH 3.7.1p1 --> connection hangs and does not close (ssh2 only) Product: Portable OpenSSH Version: 3.7p1 Platform: All OS/Version: other Status: NEW Severity: major Priority: P2 Component: sshd

> -----Original Message----- > From: Ben Lindstrom > Sent: 15 September 2003 08:53 > To: Vikash Badal - PCS > Cc: 'openssh-unix-dev at mindrot.org' > Subject: Re: SCO 3.2v4.2 and OpenSSH -current --> connection hangs and > does no t close > > go into bsd-misc.c and comment out the define and try it > again. We should > be using mysignal by default

Hi openssh-unix-dev subscribers :) I have found that ServerAliveInterval & ServerAliveCountMax have some bug. Basically the ssh-alive check function (that verify the peer is alive) is called only if no data at all gets into ssh (when it should work only for server channel).I am pretty sure developers know about this ..anyway I have tried to fix this issue. Here is the patch: diff -rNu

Hello, In response to the timing analysis attacks presented by Dawn Song et. al. in her paper http://paris.cs.berkeley.edu/~dawnsong/ssh-timing.html we at Silicon Defense developed a patch for openssh to avoid such measures. Timing Analysis Evasion changes were developed by C. Jason Coit and Roel Jonkman of Silicon Defense. These changes cause SSH to send packets unless request not to,

Hi :-) i have try a hang on exit patch that i found in the web for an old openssh version, but it dosent help :-( in a german gdb howto i found a tip that the backtrace output can help to analyse the problem.... is it a solaris problem ? Greetings Frank sshd: #0 0xff19d618 in _poll () from /usr/lib/libc.so.1 #1 0xff14d53c in select () from /usr/lib/libc.so.1 #2 0x000339a0 in

The attached patch adds an option (off by default to preserve current behavior) to set a timeout on the select() statement that waits for input in clientloop.c. This fixes a timeout issue for me (explained below) and probably also fixes the timeouts mentioned in last month's thread "Idle time out". The patch is also available by http from:

Heya, Most of the windows ssh clients (putty, securecrt) have anti-idle features. They offer either a null packet or protocol no-op or user defined string to be sent over every x seconds. Is this possible or planned with the OpenSSH client? Our draconian firewall admins have started timing out ssh sessions. Yes I'm aware I could hack up a port forwarding dumb traffic process, but was

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

In the changelog, there is an entry: 20001129 - (djm) Back out all the serverloop.c hacks. sshd will now hang again if there are background children with open fds. Does this mean that this is regarded as expected (and correct) behavior, that should not change in the future, or does it mean that this behavior is a known problem that someone will eventually fix? --Adam -- Adam McKenna

I'm reading this fine article on O'Reilly: http://linux.oreillynet.com/lpt/a//linux/2001/11/08/ssh_keystroke.html <quote> The paper concludes that the keystroke timing data observable from today's SSH implementations reveals a dangerously significant amount of information about user terminal sessions--enough to locate typed passwords in the session data stream and reduce the

Hi, I just installed OpenSSH 3.3p1 on a SunOS 4.1.4 system (actually a 3-year old Auspex file server) as a replacement for an older, probably vulnerable ssh version. I used gcc, openssl 0.9.6d, zlib 1.1.4 and the configure incantation ./configure --with-tcp-wrappers --with-privsep-user=privsep (the latter option obviously being the default value). There were two problems: (a) memmove seems