New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/crypto/ssh: Client does not wait long enough for reply from server and sends EOF #29954
Comments
can you send a client trace (set debugMux=true) of the client? You should probably wait to receive exit-status before closing the channel. |
@hanwen Here is the trace, I added also a bit of prints to better understand the logic.
|
", but then the client send EOF without waiting for the result." you are in control of the client. Why are you sending EOF if it looks like the server can't handle it? |
Sorry I do not get your comment, I am not sending EOF, it is all done within ssh client code, in my code I just call: It seems to me the client does not get blocked on a signal or something indicating that all data has already been received and ready to be consumed. |
2019/01/28 08:45:58 send(1): ssh.channelEOFMsg{PeersID:0x1}
according to this trace, it's all looking fine. client sends EOF. Server sends command exit-status back (status 0 = success). Then its stops sending data (EOF), and tears down the channel. ie. I don't understand the problem. What should have happened that you are not seeing? |
Here is the trace with 600 millisecond sleep added here: As you can see from the trace, there are 3 packets coming from the server, sizes 13, 38 and 206 bytes. Which are missing when there is no delay. What is interesting if the delay is 200 millisecond then I get only 1 packet instead of 3. I think this supports my theory that ssh client does not either wait enough or getting buffer ready signal prematurely. If you are interested, I can easily demonstrate it.
|
The original trace looked sane. As far as I can see, something is broken in the server. If the server somehow closes & tears down the channel before it sends stderr/stdout of the process, that is a bug in the server implementation. I suggest to use https://godoc.org/golang.org/x/crypto/ssh#Session.Run instead, where you can insert sleep to your heart's desire. (for the record, what is the type of cisco device, and what version of the firmware is it running?) |
It is funny, first I opened a bug for the server side, but it was confirmed from debugs that it is
The issue is experienced with any routers running IOS-XR code. I tried on multiple platforms, CRS. ASR9k, xrvr and xrv9k with codes 6.1.3, 6.4.2, 7.0.1. |
client sending EOF means that the client is not going to send more data. It does not mean the channel is to be torn down. See https://tools.ietf.org/html/rfc4254#section-5.3 " Note that the channel remains open after this message, and |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputGOARCH="amd64"
GOBIN=""
GOCACHE="/Users/sbezverk/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/sbezverk/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/8r/m13mcmf15z3d0dq7d412rnph0000gn/T/go-build111235926=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
I am using "golang.org/x/crypto/ssh" library to run remotely commands against ssh server which is a cisco router. Router's debug shows that the client sends successfully command, but then the client send EOF without waiting for the result.
What did you expect to see?
Client should receive server's reply
What did you see instead?
Client does not receive data from the server.
The workaround I found was adding a 1 second delay at this line:
https://github.com/golang/crypto/blob/master/ssh/channel.go#L591
The text was updated successfully, but these errors were encountered: