similar to: connection forwarding troubles

For some time I have routinely websurfed across a forwarded TCP connection using SSH. The other end of the TCP tunnel connects to a Squid proxy cache on the same machine. This usually works. But I see lots of error messages on each end of the form Jun 13 13:22:02 tunnel sshd[32378]: error: channel 0: chan_shutdown_read: shutdown() failed for fd5 [i1 o128]: Transport endpoint is not connected

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 openssh-1.2.1pre20 has been released at: http://violet.ibs.com.au/openssh/files/ This release integrates more of Andre Lucas' portability patch, Ben Taylor's utmpx patch and some cleanups and bugfixes of my own. The auth-passwd failures should be fixed, as should lastlog support on NetBSD. Since Andre Lucas' patch included platform

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 openssh-1.2.1pre20 has been released at: http://violet.ibs.com.au/openssh/files/ This release integrates more of Andre Lucas' portability patch, Ben Taylor's utmpx patch and some cleanups and bugfixes of my own. The auth-passwd failures should be fixed, as should lastlog support on NetBSD. Since Andre Lucas' patch included platform

Scenario: Use the ssh-keygen utility in openssh-1.2pre17 to generate a host key Kill and restart sshd Remove the old host key from ~/.ssh/known_hosts Connect to the host using ssh. I get this: homer.ka9q.ampr.org$ ssh 199.106.106.3 who The authenticity of host '199.106.106.3' can't be established. Key fingerprint is 1024 a0:8d:17:f0:fa:a9:9f:6f:b5:d0:1c:d6:02:92:bd:5e. Are you sure

There's one vulnerability that's bugged me for some time. It applies to nearly all crypto software, including ssh. That's the swapping of sensitive info (such as keys and key equivalents) onto hard drives where they could possibly be recovered later. The Linux kernel provides a system call, mlock(), that inhibits swapping of a specified region of virtual memory. It locks it into real

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:

Has anyone heavily exercised the TCP connection forwarding features in openssh? I use this feature quite extensively for secure web surfing. I run a ssh command like this: ssh -c blowfish -L3128:127.0.0.1:3128 squidmachine Then I set up Netscape on my local machine to use 127.0.0.1:3128 as a proxy server. Needless to say, this exercises the TCP connection forwarding feature quite heavily. This

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 have recently compiled and installed openssh-2.1.1p1 on a linux box. The login reporting does not seem to work properly. When logging into the box via ssh (protocol 1) utmp shows the user logged in and the tty properly, but the field for the login date/time and the field for originating host contain all NULLs. Is anyone else seeing this same behavior, or have I just done something really

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

Hi. To compartmentalize things a bit (e.g., to help limit the damage should one of my machines be hacked and my private RSA keys stolen) I use different RSA key pairs on my different client machines. So it occurs to me that it would be nice if ssh could log which key was used when logging in to a particular account that has more than one entry in .ssh/authorized_keys. Right now it simply says

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

Hi. I saw a new release appear today, and I pulled it down to see if some residual problems in port forwarding from openssh-1.2.3 were fixed. The configure script had trouble finding the openssl package, even though I had it installed in the standard place (/usr/local/ssl). I investigated and found that the failed test compile was caused by two nonfatal compiler warnings that memset and RAND_add