similar to: OpenSSH solaris: bad return code after exec of remote command

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

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,

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

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 4.6p1 sshd is logging this error during remote commands or file transfers: error: channel 0: chan_read_failed for istate 3 Platform is Solaris 8, 4.6p1 + OpenSSL 0.9.8d. The commands and transfers work correctly, so the error message appears to be spurious. The error message does not appear when processing logins. Otherwise 4.6p1 is running without any apparent problems. This error

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

Hello, ? I need to make many (>50) ssh connections from linux to cygwin at the same time. Using Windows 2000 Server (OpenSSH_4.3p2, OpenSSL 0.9.8b and updated cygwin) and Linux RHEL4 (OpenSSH_3.9p1, OpenSSL 0.9.7a). ? It's been difficult to optimize many simultaneous connections. Here were some issues: 1.?????? On Windows XP/Professional, Microsoft intentionally cripples the TCP/IP stack.

Hi! I am resending the following message about problems with utmp handling. * In the meantime I had some request in private mail from people asking whether I have new information. * The problem is still persistant in 2.9p2. * My own new investigations show, that the problem only appears with protocol 2, not with protocol 1, I therefore only started to note it when protocol 2 became the

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

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,

comments? alternatives: sigsetjmp(ugly) and pselect(not portable, available) drawback: additional filedescriptors. Index: serverloop.c =================================================================== RCS file: /home/markus/cvs/ssh/serverloop.c,v retrieving revision 1.82 diff -u -r1.82 serverloop.c --- serverloop.c 10 Oct 2001 22:18:47 -0000 1.82 +++ serverloop.c 11 Oct 2001 18:06:33 -0000 @@

http://bugzilla.mindrot.org/show_bug.cgi?id=1131 ------- Comment #18 from cove at wildpackets.com 2006-03-17 09:06 ------- It could be a bug in cryptlib, but I had the same problem with libssh and the first comment in this bug report is with a 3rd implementation. debug2: load_server_config: filename /usr/local/etc/sshd_config debug2: load_server_config: done config len = 292 debug2:

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.

In our work with enabling large windows for openssh we found 1) that if a window > 0x10000 is advertised to openssh's sshd 2) the sshd tries to send more than 0x10000 bytes of data 3) the receiver does not consume them 4) the input buffer will grow larger than the size allowed by buffer.c and fatal(). We believe the correct behavior is to limit reading into the channel input buffer to

Hi, I'm a newbie to openssh and was trying to read the source code recently. Could anyone tell me why in sshd the connection_in and connection_out are the same(seems to be integer 3 in my machine). connection_in is used in process_input(readset), and connection_out is used in process_output(writeset); But how does it work if it tries to read and write from the same file descriptor? /Bob

https://bugzilla.mindrot.org/show_bug.cgi?id=1967 Bug #: 1967 Summary: Potential memory leak Classification: Unclassified Product: Portable OpenSSH Version: 5.9p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: unassigned-bugs at