Every time I open an SSH Tunnel to my server after visiting a few sites over it I get the following error: channel_by_id: 3: bad id: channel free Disconnecting: Received ieof for nonexistent channel 3. The channel number varies but it's always the same issue. Any help would be appreciated. The server I'm using is for FreeSSHd for Windows. I'm connecting to the tunnel with ssh -N User at host -D 1080. Thanks. Verbose: OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to <host> port 22. debug1: Connection established. debug1: identity file /home/user/.ssh/id_rsa type -1 debug1: identity file /home/user/.ssh/id_rsa-cert type -1 debug1: identity file /home/user/.ssh/id_dsa type -1 debug1: identity file /home/user/.ssh/id_dsa-cert type -1 debug1: identity file /home/user/.ssh/id_ecdsa type -1 debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/user/.ssh/id_ed25519 type -1 debug1: identity file /home/user/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 debug1: Remote protocol version 2.0, remote software version WeOnlyDo 2.1.3 debug1: no match: WeOnlyDo 2.1.3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY debug1: Server host key: RSA key debug1: Host '<host>' is known and matches the RSA host key. debug1: Found key in /home/user/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: password,publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/user/.ssh/id_rsa debug1: Trying private key: /home/user/.ssh/id_dsa debug1: Trying private key: /home/user/.ssh/id_ecdsa debug1: Trying private key: /home/user/.ssh/id_ed25519 debug1: Next authentication method: password User at host's password: debug1: Authentication succeeded (password). Authenticated to <host>. debug1: Local connections to LOCALHOST:1080 forwarded to remote address socks:0 debug1: Local forwarding listening on ::1 port 1080. debug1: channel 0: new [port listener] debug1: Local forwarding listening on 127.0.0.1 port 1080. debug1: channel 1: new [port listener] debug1: Entering interactive session. debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 2: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 3: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 4: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 5: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 6: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 7: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 8: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 9: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 10: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 11: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 12: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 13: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 14: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 15: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 16: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 17: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 18: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 19: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 20: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 21: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 22: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 23: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 24: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 25: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 26: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 27: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 28: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 29: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 30: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 31: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 32: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 33: new [dynamic-tcpip] debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 34: new [dynamic-tcpip] debug1: channel 10: free: direct-tcpip: listening port 1080 for connect.facebook.net port 80, connect from 127.0.0.1 port 51036 to 127.0.0.1 port 1080, nchannels 35 debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 10: new [dynamic-tcpip] debug1: channel 11: free: direct-tcpip: listening port 1080 for connect.facebook.net port 80, connect from 127.0.0.1 port 51037 to 127.0.0.1 port 1080, nchannels 35 debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 11: new [dynamic-tcpip] debug1: channel 33: free: direct-tcpip: listening port 1080 for cdn.syndication.twitter.com port 80, connect from 127.0.0.1 port 51059 to 127.0.0.1 port 1080, nchannels 35 debug1: Connection to port 1080 forwarding to socks port 0 requested. debug1: channel 33: new [dynamic-tcpip] debug1: client_input_channel_req: channel 10 rtype exit-status reply 0 debug1: client_input_channel_req: no sink for exit-status on channel 10 debug1: channel 10: free: direct-tcpip: listening port 1080 for webchat.freenode.net port 80, connect from 127.0.0.1 port 51061 to 127.0.0.1 port 1080, nchannels 35 channel_by_id: 10: bad id: channel free Disconnecting: Received ieof for nonexistent channel 10.
On Wed, Dec 3, 2014 at 6:26 PM, Junk <junk at private.rw-gs.net> wrote:> Every time I open an SSH Tunnel to my server after visiting a few sites > over it I get the following error: channel_by_id: 3: bad id: channel free > Disconnecting: Received ieof for nonexistent channel 3. The channel number > varies but it's always the same issue. Any help would be appreciated. The > server I'm using is for FreeSSHd for Windows. I'm connecting to the tunnel > with ssh -N User at host -D 1080. Thanks. > > > Verbose: >Looks like this is only debug level 1, debug level 3 (ssh -vvv) might provide more information. [...]> debug1: Local connections to LOCALHOST:1080 forwarded to remote address > socks:0 > debug1: Local forwarding listening on ::1 port 1080. > debug1: channel 0: new [port listener] >channel 0 is a port forward channel. Note that there is not shell channel because you used -N to not ask for one. This should be fine. [...]> debug1: Connection to port 1080 forwarding to socks port 0 requested. > debug1: channel 10: new [dynamic-tcpip] >channel 10 is assigned to a port forward channel. this should also be fine. [...]> debug1: channel 10: free: direct-tcpip: listening port 1080 for > connect.facebook.net port 80, connect from 127.0.0.1 port 51036 to > 127.0.0.1 port 1080, nchannels 35 >channel 10 is freed by the server. also fine.> debug1: Connection to port 1080 forwarding to socks port 0 requested. > debug1: channel 10: new [dynamic-tcpip] >channel 10 is reused. also fine. [...]> debug1: client_input_channel_req: channel 10 rtype exit-status reply 0 > debug1: client_input_channel_req: no sink for exit-status on channel 10channel 10 gets an exit-status message. This is not fine: channel 10 is a port forward (direct-tcpip) ssh channel, so this should not happen (see rfc4254 section 6.10). I suspect it also causes the client to tear the channel down, although I have not checked this.> debug1: channel 10: free: direct-tcpip: listening port 1080 for > webchat.freenode.net port 80, connect from 127.0.0.1 port 51061 to > 127.0.0.1 port 1080, nchannels 35 > channel_by_id: 10: bad id: channel free > Disconnecting: Received ieof for nonexistent channel 10. >The client receives a channel free for channel 10, but as per the previous comment I suspect it's already torn down at this point. This goes off the rails when the server sends an exit-status message for something that's not a shell command. This is probably a server bug, but maybe the openssh client could ignore these (it's a protocol violation, though). Depending on exactly what's going on in the server, you may be able to work around the problem by specifying a long-running command (eg "sleep 999999" or similar) instead of -N. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.