similar to: TCP connection forwarding troubles

The Linux implementation of TCP sockets has a bug which causes shutdown(sock, SHUT_RD) to fail spuriously (ENOTCONN) if the write side of the socket has already been shut down. If you are using SSH port forwarding to tunnel HTTP through a firewall, nchan.c will tickle this bug once for every HTTP exchange. You will therefore get lots of useless, annoying error messages: channel 2:

Hi, Thank you for the great OpenSSH package. I obtained 1.2.2 and tried it on linux 2.2.14. I had reported earlier that I saw "Transport endpoint is not connected" warning messages were observed on the linux 2.2.14 kernel with earlier release of openssh. The same happens when I used the port-forwarded HTTP connection. But this time, after accessing such http connections, I noticed

I have been using OpenSSH for a while, and I would like to thank you for the great package. Here is a report of mysterious warning message lines, I get while I use OpenSSH. They don't seem to be serious, but annoying nevertheless. version: openssh-1.2.1pre27 OS Linux standard 2.2.14 #18 SMP Thu Jan 6 06:07:45 JST 2000 i586 unknown (compiled with gcc 2.95.2) Compiler gcc -v Reading

I'm still seeing problems when I use TCP connection forwarding across SSH to surf the web. I see lots of error messages of the form channel 1: chan_shutdown_read: shutdown() failed for fd7 [i1 o128]: Transport endpoint is not connected And I see occasional connection lockups. Both ends are running openssh-2.1.1p1. Phil

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

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,

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:

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:

https://bugzilla.netfilter.org/show_bug.cgi?id=1221 Bug ID: 1221 Summary: "fib" produces strange results with an IPv6 default route Product: nftables Version: unspecified Hardware: x86_64 OS: Debian GNU/Linux Status: NEW Severity: major Priority: P5

When I run this command: ssh -1 -v -n -l root njdb1b /usr/bin/X11/xterm -sb -sl 1000 -T njdb1b -e find /etc An xterm appears on my screen, the contents of /etc scroll by and then ssh exits. When I invoke the same command with the -2 option, the xterm appears (and disappears) but ssh never exits. netstat says the (ssh) connection is still established but the xterm is no longer

I've been using rsync under Win2k(cygwin) for some time without error. But after a recent upgrade of cygwin I've started to get errors, and rsync no longer works. I'm not sure if this is a rsync problem, ssh problem, or cygwin problem, so I figured I'd try here first (since ssh seems to work fine). On my windows machine: > rsync --version rsync version 2.5.6 protocol

Three possibly related bugs to report. N.B. The test machines in question are in peak form (with the exception of different kernel versions) and were working 100% under the old ssh 1.2.x. The two clients we tested from are machines running 2.2.13 & 2.2.14preX Linux kernels. The server where the problems appeared is running 2.2.12. 1. sshd dies periodically. The crash occurred just after a

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

Hello, I have a question because POSIX ACL with SMB2 max protocol does not work properly.Did you test VFS xattr acls with SMB2 max protocol? Is it working corectly? Best regards/Adrian Berlin --

Version: OpenSSH_2.5.2p2, SSH protocols 1.5/2.0, OpenSSL 0x0090601f Platform: RedHat Linux 7.0 and Sun Solaris 2.6 I have the following problem: when I set up port forwarding for HTTP, running Squid at one end as an HTTP proxy and a browser at the other end (Netscape, IE) everything works fine, I can tunnel HTTP requests through OpenSSH but I keep seeing the following error messages that mess up

Hi, We installed OBSD's ssh package on production and find our batch jobs are hanging on the "ssh" command. The details are included below, for both normal and "hanging" executions. Please let me know if this is a new or existing bug or if you require further info to debug this. The command was executed with the highest debug level (-v -v -v for level 3). This script

I am trying to resolve an issue with SSH2 version 2.5.2p2 on Solaris 2.6. SSH2, SSH1 and SCP all work fine in and out. The problem is with SFTP. I can SFTP out, but not in. I can't SFTP into itself. After I issue the command, I get a password prompt. After I give the password, the connection closes with an Exit Status 127. There are 3 other system configure the same and everything is

Here's the appropriate output with blow-by-blow explanation embedded... I start by making a connection with X11 forwarding enabled: polycut:~> ssh -v -v -v -X dazel OpenSSH_2.9.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /opt/openssh-2.9.9p2/etc/ssh_config debug3: Reading output from 'ls -alni /var/log' debug3: Time elapsed: 23 msec debug3:

Hi, I just grabed the 2.9p2 and can't forward X11 connections. This worked fine for me under 2.9p1 but with 2.9p2 it seems that $XAUTHORITY isn't getting set and when I try and set it manually connections to the Xserver still fail with: debug1: X11 connection uses different authentication protocol. debug1: X11 rejected 1 i1/o16 Verbose debugs below. client: OpenSSH_2.9p1, SSH

I have a few bug reports and some comments after upgrading from SSH 1.2.27 to OpenSSH 2.9p2 at a large university. OpenSSH often fail to return the correct exit status from the remote command if small amounts of data are transfered, SSH version is 2 and ssh is run with no STDIN or with the -n option. Below is an example. Authentication method is hostbased and the file sizes are 1KB, 4KB and 8KB: