similar to: Read buffer size in clientloop.c

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

Hi folks, Could you tell me which function in clientloop.c is responsible for reading user keyboard input? What I found are client_make_packets_from_stdin_data() and client_process_input(), but they not for 'compat20' mode. My app runs in 'compat20'. Thanks, Bob

We have been using OpenSSH version 2.3.0p1 for a couple of months now with out problems. The same goes for several previous versions we have used over the last year. However, I have just installed version 2.5.2p2 and it is giving me some problems. If it were not for the latest security bulletins strongly suggesting we upgrade, I would reinstall the 2.3.0p1 version. I am running on a SGI

Hi all, currently I am considering writing a patch for OpenSSH that will allow portforwarding using the control_master unix domain socket. The idea is to introduce an extra SSHMUX command, SSHMUX_COMMAND_SOCKS, which will then pass control to the normal socks functions used for dynamic forwarding. The main reason for me to write this patch are: - some more control over who gets to connect to

Hi, could somebody with checkin rights please apply the below patch? A while back we set SSH_IOBUFSZ, the size of the IO buffers used by ssh, to 65536 for Cygwin, which resulted in a noticable speed up of the connection. However, due to constraints in Windows Sockets in terms of socket inheritance, we had to reduce the default SO_RCVBUF/SO_SNDBUF buffer size in Cygwin from 65536 to 65535. The

Previous version compiled successfully was 5.5p1. Now compiling 5.8p1 on the same machine "AIX 5.3 TL12 SP2" via GNU make with gcc 4.2.0 - got an error, can someone help with this? gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o mux.o roaming_common.o roaming_client.o -L. -Lopenbsd-compat/ -L/usr/local/lib -Wl,-blibpath:/usr/lib:/lib:

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

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:

I am running OpenSSH 2.9p1 on SunOS 5.7 w/4-24-2001 patch cluster. Like many other users I am seeing the hanging session on logout with background processes. This is a huge problem for me as I centrally manage 50+ machines with rdist across ssh. Instead of just complaining about the problem I thought I would put my CS degree to use and try to track down the problem myself. For starters,

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.

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

http://bugzilla.mindrot.org/show_bug.cgi?id=160 Summary: Race condition in clientloop.c? Product: Portable OpenSSH Version: 3.0.2p1 Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: Nicolas.Williams

https://bugzilla.mindrot.org/show_bug.cgi?id=1548 Summary: Double free in OpenSSH clientloop.c/xmalloc.c via cmdline port forwarding Product: Portable OpenSSH Version: 5.1p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo:

http://bugzilla.mindrot.org/show_bug.cgi?id=160 ------- Additional Comments From Nicolas.Williams at ubsw.com 2002-03-13 09:10 ------- Created an attachment (id=40) Debug output, lsof output, etc... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

Hi! as I just noted, after scp the connection does not shut down properly. When I do a "scp file targethost:path", on targethost a "sshd" process is left running. I do use --with-default-path="/usr/local/openssh/bin:/usr/bin:/usr/local/bin" to assure, that the corrensponding openssh-scp is used. It also seems, that normal sessions are not always closed properly.

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

This change allows use of untrusted X11 forwarding (which is more secure) without requiring users to choose a finite timeout after which to refuse new connections. This matches the semantics of the X11 security extension itself, which also treat a validity timeout of 0 on an authentication cookie as indefinite. Signed-off-by: Trixie Able <table at inventati.org> --- clientloop.c | 12

Hello, I just ran upon this problem and couldn't find it in bugzilla. SSH crashes (abort trap) if all of the following conditions are met: (a) option -f is used (crash happens when going to background), (b) reverse port forwarding is set up (option -R), (c) option ExitOnForwardFailure is enabled, (d) there are no actual port-forwarding failures. The problem can be reproduced by

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

On Wed, 8 Nov 2023, Roger Marsh wrote: > Damien, > > Sorry about distributed context. > > Those discussions told me about the new ObscureKeystrokeTiming > argument to the ssh command. One reply suggested I try that because it > is easy to test. > > Most of my xterm ssh command combinations in fvwm configuration file > are expressed 'Exec exec xterm -title ... -e