4

The log below is from SSHD server when SSH client is trying to connect. I'm sure that I have correct ssh key. I just compared two RHEL5 servers. As I red, this means that server closed the connection for some reason. But any suggestions how to try to solve the issue and find the root cause?

Jul 29 20:12:11 sshd[13259]: subsystem request for sftp
Jul 29 20:12:11 sshd[13259]: channel_by_id: 0: bad id: channel free
Jul 29 20:12:11 sshd[13259]: Disconnecting: Received data for nonexistent channel 0.

OS: RHEL 5.11, SSHD service: default

laimison
  • 579
  • 2
  • 9
  • 17

5 Answers5

2

I was getting this error because the server was out of disk space. Deleting some large files solved the issue and I was able to SFTP files to it again.

mad_fox
  • 121
  • 1
2

The error message Disconnecting: Received data for nonexistent channel 0. might be caused by incorrect sshd configuration.

Check if the line Subsystem sftp /usr/lib/openssh/sftp-server (or similar) in /etc/ssh/sshd_config points to the correct binary.

Another cause for the error could be an incorrect setting system shell setting in /etc/passwd for the user. source

Henrik Pingel
  • 9,380
  • 2
  • 28
  • 39
  • 1
    Thanks for ideas. In my case, it doesn't help. `/etc/passwd` has identical entry and `sshd_config` has no differences between successful and failed host. sftp parameter is `Subsystem sftp /opt/quest/libexec/sftp-server` which could be the issue even if one host is successful with that. I'm not sure how to test/debug this sftp-server separately from SSHD service. – laimison Aug 09 '16 at 12:57
  • 1
    I would try to disable sftp server by commenting `# Subsystem sftp /usr/lib/openssh/sftp-server` and restarting the ssh server. If you are lucky Jenkins will fall back to scp. – Henrik Pingel Aug 09 '16 at 13:03
0

On Oracle Linux 8 the reason for this message was an expired user password. We configured user1 to SFTP-only access, and when we tried to access SFTP-share using the private key for this user1 we got the same error. For Oracle Linux 8 you could check password expire using the command:

# chage -l user1

Look at the Password expires row. After we changed the password, we got a working account.

denixx
  • 1
0

Check

/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_time_wait

Or

/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_close_wait

I was looking for a solution to reduce the amount of XXX_WAIT on my server

[mihamina@RKTMB ~]$ sudo ss -taupen | grep WAIT
tcp    TIME-WAIT  0      0      127.0.0.1:3128               127.0.0.1:60036               timer:(timewait,15sec,0) ino:0 sk:ffff9bbf5ba65000
tcp    TIME-WAIT  0      0      127.0.0.1:3128               127.0.0.1:60024               timer:(timewait,1.420ms,0) ino:0 sk:ffff9bbee4aa2300
tcp    TIME-WAIT  0      0      127.0.0.1:59994              127.0.0.1:3128                timer:(timewait,54sec,0) ino:0 sk:ffff9bbf5ba64c00
tcp    TIME-WAIT  0      0      127.0.0.1:60028              127.0.0.1:3128                timer:(timewait,2.467ms,0) ino:0 sk:ffff9bbee4aa2600
tcp    TIME-WAIT  0      0      127.0.0.1:59946              127.0.0.1:3128                timer:(timewait,23sec,0) ino:0 sk:ffff9bbf5ba65900
tcp    TIME-WAIT  0      0      127.0.0.1:3128               127.0.0.1:60032               timer:(timewait,7.045ms,0) ino:0 sk:ffff9bbee4aa2800
tcp    TIME-WAIT  0      0      127.0.0.1:60030              127.0.0.1:3128                timer:(timewait,5.521ms,0) ino:0 sk:ffff9bbee4aa2a00
 ... # I have a Loooooottt

And I found https://www.lognormal.com/blog/2012/09/27/linux-tcpip-tuning/

But if you read carefully, they warn about packets mess...

Mihamina Rakotomandimby
  • 861
  • 6
  • 4
-1

Received SSH2_MSG_CHANNEL_DATA for nonexistent channel 0 winscp

El problema ocurre porque está llena la partición donde se intenta subir el archivo. Un saludo.

Juan Fernando Arango
  • 1