1

When I work with ssh tunnel, I get the following message repeatedly:

debug3: channel x(a number): will not send data after close

What does it mean?

I also get the following messages:

debug2: channel 3: open confirm rwindow 2097152 rmax 32768
debug2: channel 4: open confirm rwindow 2097152 rmax 32768
debug2: channel 3: rcvd eof
debug2: channel 3: output open -> drain
debug2: channel 7: rcvd eof
debug2: channel 7: output open -> drain
debug2: channel 7: obuf empty
debug2: channel 7: close_write
debug2: channel 7: output drain -> closed
debug2: channel 7: rcvd close
debug2: channel 4: rcvd eof
debug2: channel 4: output open -> drain
debug2: channel 31: rcvd close
debug2: channel 34: rcvd close
debug2: channel 35: rcvd close
debug2: channel 18: rcvd eof
debug2: channel 18: output open -> drain
debug2: channel 18: obuf empty
debug2: channel 18: close_write
debug2: channel 18: output drain -> closed
debug2: channel 18: rcvd close
debug3: channel 7: will not send data after close
debug3: channel 18: will not send data after close
debug3: channel 31: will not send data after close
debug3: channel 34: will not send data after close
debug3: channel 35: will not send data after close
debug2: channel 7: send close
debug2: channel 7: is dead
debug2: channel 7: garbage collecting`

Is there anything wrong?

|improve this question
2

You're seeing these messages because you're running ssh with multiple -v options. Unless you're trying to debug a problem with ssh you can safely ignore these messages, or just not run ssh with -v. If there's a problem that you need to deal with, ssh will output an error message that you can see without using -v.

In the case of this message, it is being generated because one of the data channels ssh is handling has buffered data waiting to be sent to it, but the channel has been closed. ssh is going to discard the data and the debug message is just an acknowledgement of that fact.

|improve this answer
  • I enabled verbose mode because connection is too slow. Do any of the above messages affect on speed? – hknik Apr 6 '12 at 21:14
  • 1
    Nope, nothing related to speed. – Kyle Jones Apr 6 '12 at 21:27
  • 2
    @hknik: There are better ways to chase a speed problem than -vvv. You really should start by quantifying the speed, or lack thereof. If it's bulk data transfers you're concerned about, time an scp command. If there's a high latency on keystrokes in interactive sessions, run a packet capture on the session (e.g. tshark -w) then analyze it in Wireshark; the Statistics menu is helpful for this sort of thing, as are the timestamp values and a calculator. All this would be a separate question, though. – Warren Young Apr 6 '12 at 22:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.