similar to: channel->input buffer bug and patch

As before, it is described on our website. This should apply fairly cleanly to both portable and openbsd ssh. http://www.psc.edu/networking/hpn-ssh/ Only in openssh-3.8.1p1-dynwindow: Makefile diff -u openssh-3.8.1p1/buffer.c openssh-3.8.1p1-dynwindow/buffer.c --- openssh-3.8.1p1/buffer.c 2003-11-21 07:56:47.000000000 -0500 +++ openssh-3.8.1p1-dynwindow/buffer.c 2004-07-12 07:49:29.000000000

I am utilizing an openssh tunnel between two Linux boxes. On the client box I issue the following commands to set up the tunnel; - ssh -w0:0 root at x.x.x.x -v where x.x.x.x is the IP address of the Linux system running sshd - ip addr add 10.0.5.1/32 peer 10.0.5.2 dev tun0 - ip link set tun0 up On the box running sshd I issue the following commands: - ip addr add 10.0.5.2/32 peer 10.0.5.1 dev

Using OpenSSH_8.3p1 I had an open (working) connection to some other box; after a bit of inactivity, some device in the middle seems to have forgotten about the TCP connection (NAT) and broke it. I've got an EscapeChar defined, though; so first I tried to send a BREAK and, when that didn't help (TCP already gone, packets get lost!), I tried (just out of curiosity) a Rekey. Now I can see

The command "ssh ls -l /doesnotexist" gives various responses: Running from a 200 MHz PentiumPro with dsa key added to ssh-agent: Mistakes worst to fast machine: To a faster 600 MHz dual processor i686 600 MHz machine: ls: /doesnotexist: No such file or directory -- correct nothing at all -- wrong ls: select: Bad file descriptor -- wrong

Hi, I am facing an issue with openssh-4.5p1. I am not sure whether its an openssh issue or a tcp stack issue since I am using a simulated tcp/ip stack. While copying a file of around 1GB using sftp/scp I am getting a send:Message too long error. I did a bit of debugging and found that ssh code was sending packet of size greater than 131072 bytes from the application level to the socket and

this (uncomplete) patch makes various features compile time options and saves up to 24K in the resulting ssh/sshd binaries. i don't know whether this should be added to the CVS since it makes the code less readable. perhaps WITH_COMPRESSION should be added, since it removes the dependency on libz -m Index: Makefile.inc =================================================================== RCS

Hi, At the n2k10 OpenBSD network hackathon, I finally got some time to clean up and rewrite the ssh(1) client multiplexing code. The attached diffs (one for portable OpenSSH, one for OpenBSD) are the result, and they need some testing. The revised multiplexing code uses a better protocol between the master and slave processes and I even bothered to write it up :) It tracks the control sockets

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,

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

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,

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,

We have developed a patch that enables changing the SSH window size using the tcp window size as the source. This allows SSH to obtain maximum use of the bandwidth on high BDP links. We also have a page that describes the changes and performance. http://www.psc.edu/~rapier/hpn-ssh/ The patch against CVS is included here. Common subdirectories: src/usr.bin/ssh/CVS and ssh/CVS diff -u

Hi all, This is a client side only implementation of reversed dynamic (SOCKS) TCP forwarding, which means it is compatible with any existing servers have 'remote forward' capability. To establish such forward, use "ssh -R [BIND_ADDRESS:]PORT ...". The server will listen on that port and address and accept SOCKS traffics. Hope this will be useful for you. There was an

The current code for channel.c creates an array of Channel structs (initially set to NULL) which is then iterated through, in full, every time a channel needs to be dealt with. If only one channel is in use, which is relatively common, the code still loops through the entire array. This patch creates a linked list of pointers to these structs and the code steps through the linked list. Since

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:

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

here's an up-to-date patch, should apply to both openbsd and non-openbsd versions of openssh. i did only test ipv4 addresses. Index: channels.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.191 diff -u -r1.191 channels.c --- channels.c 24 Jun 2003 08:23:46 -0000 1.191 +++ channels.c 25 Jun 2003 12:14:19

When I encounter the problem with TCP port forwarding locking up, I'll see this on the client window (if I haven't invoked ssh with -q): chan_shutdown_read failed for #1/fd6: Transport endpoint is not connected chan_shutdown_read failed for #1/fd6: Transport endpoint is not connected This is with Blowfish encryption. I have to kill and restart the client when this happens. Phil

Hi OpenSSH developers, I am using openSSH (now 2.9.9p2, but prob occurs in 2.9p2 also) to execute commands on a remote machine which outputs data to stdout then pipes it to another invocation of ssh which connects back to the first machine in the same way, where it starts a program to read and store the output from the command on the second machine. I am using the "command" option in

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: