similar to: [Bug 1306] Spurious : "chan_read_failed for istate 3" errors from sshd

http://bugzilla.mindrot.org/show_bug.cgi?id=1306 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #1281| |ok? Flag| | --- Comment #7 from Damien Miller <djm at

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, We have upgraded the openssh 4.6P1 on Solaris 8 servers. After upgrade we get the below error message whenever we execute the remote commands using ssh. Please let me know what the fix is for this. Apr 8 03:03:43 dvsrv10 sshd[25379]: [ID 800047 auth.info] Accepted publickey for osteam from 10.0.93.31 port 35856 ssh2 Apr 8 03:03:50 dvsrv10 sshd[25381]: [ID 800047 auth.error] error:

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

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

https://bugzilla.mindrot.org/show_bug.cgi?id=1525 Summary: error: channel 0: chan_read_failed for istate 3 Product: Portable OpenSSH Version: 4.6p1 Platform: Other OS/Version: Other Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: unassigned-bugs at mindrot.org

Hello, The error message in the subject line occurs with the new 2.3.0 openssh version and appeared in the previous snapshots on our Solaris systems. As far as I remember it was reported, but have not seen any more about this. I have looked into it a little bit. First, the file session.c (line 1849 onwards): debug("session_exit_message: release channel %d", s->chanid);

Hi, when scp'ing a file from hostA to hostB I receive following error message on the server side. Message in authlog: Jan 9 15:01:32 zapphod sshd[3229]: [ID 800047 auth.error] error: channel 0: chan_read_failed for istate 3 The file itself is transfered correctly, so I'm wondering why this error is being logged and what this error message means It seems that the occurance of this

Hi, when scp'ing a file from hostA to hostB I receive following error message on the server side. Message in authlog: Jan 9 15:01:32 zapphod sshd[3229]: [ID 800047 auth.error] error: channel 0: chan_read_failed for istate 3 The file itself is transfered correctly, so I'm wondering why this error is being logged and what this error message means It seems that the occurance of this

Hallo all! I've found a repeatable problem concerning openssh 2.3.0p1 running on a Linux-box with kernel 2.2.17. I compiled ssh from sources with pam-support. Let me describe what I'm doing: rsync -e ssh --delete --exclude "/Daten/test*" --exclude /Daten/anonymous --exclude /Daten/comp_logs --exclude /Daten/ehemalige_rwgsysm/cache --exclude

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,

Using openssh-SNAP-20001016 all of our problems with hanging connections have gone away (woohoo!), and it seems to be working flawlessly, but I am seeing messages like this in syslog: Oct 24 16:57:48 dhumb301 sshd[17752]: error: channel 0: internal error: we do not read, but chan_read_failed for istate 8 Oct 24 16:57:59 dhumb301 sshd[17771]: error: select: Bad file descriptor Oct 24 16:58:30

Hi, I had previously noticed some peculiar log entries of the form error: error: channel 0: internal error: we do not read, but chan_read_failed for istate 8 in my logs. They were harmless as far as I was concerned. I checked the list archives, where the same logs have been reported and no solution was presented. Recently I tried to use rsync over ssh for backup purposes. The remote end

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

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:

hello, i'm getting a very strange error in my system logs. maybe someone can help out. the server is an hp-ux 11.00 box, running openssh 2.3.0p1, and the client is a redhat 6.2 box running the same version. running 'ssh -l root espage ls' from the hp box to the linux box yields this jem in the syslog. Nov 16 14:41:49 espage sshd[23974]: error: channel 0: internal error: we do not

Log snippet: channel 10: istate 4 != open channel 10: ostate 64 != open channel 11: istate 4 != open channel 11: ostate 64 != open channel 12: istate 4 != open channel 12: ostate 64 != open channel 13: istate 4 != open channel 13: ostate 64 != open channel 14: istate 4 != open channel 14: ostate 64 != open channel 15: istate 4 != open channel 15: ostate 64 != open % ssh -V SSH Version

Hello Sir, Could provide the solution for the below error ? chan_read_failed for istate 3 Thanks and regards Chandra Prakash Vela Global Operations - Production Engineering Services Computer Sciences Corporation India Private Limited C-24 ,Sector 58,Noida -201301 USA: 1-302-781-1010 Extn. 1957 UK: +44 (0) 870 850 3512 Extn. 1957 Australia: 1800 137 784 Extn. 1957 India: +91-120-2582323

Hi list, openssh-2.3.0p1 (compiled from sources) under Linux RH kernel 2.2.16 with this line in sshd-conf: Subsystem sftp sftp-server fails when trying to connect from F-secure SSH sftp client (FTP 4.1 Build 12). Connection is immediately terminated, with following error message in the log: > Nov 20 14:31:30 tor sshd[23159]: subsystem request for sftp Nov 20 > 14:31:30 tor sshd[23159]:

Hi, we are using OpenSSH_2.3.0p1. When using non-interactive mode, sometimes lines are swallowed from standard output: root at hydra:~ # ssh anderson "ls -l /usr/sbin/sshd" -rwxr-xr-x 1 root root 612344 Nov 25 20:26 /usr/sbin/sshd root at hydra:~ # ssh anderson "ls -l /usr/sbin/sshd" root at hydra:~ # ssh anderson "ls -l /usr/sbin/sshd" -rwxr-xr-x 1