Skip to content
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 swallows first character in second connection #41390

Open
jkohen opened this issue Sep 15, 2020 · 7 comments
Open

x/crypto: SSH swallows first character in second connection #41390

jkohen opened this issue Sep 15, 2020 · 7 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@jkohen
Copy link
Contributor

jkohen commented Sep 15, 2020

What version of Go are you using (go version)?

$ go version
go version go1.15 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/usr/local/google/home/jkohen/.cache/go-build"
GOENV="/usr/local/google/home/jkohen/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/usr/local/google/home/jkohen/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/usr/local/google/home/jkohen/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/google-golang"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/google-golang/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
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=/tmp/go-build079540723=/tmp/go-build -gno-record-gcc-switches"

What did you do?

The following assumes a ssh server in localhost set up with SSH_AUTH_SOCK, which is what my environment provides. It should be trivial for you all to adjust it for a different host and hardcoded password as needed:

  1. go run xcrypto-bug.txt
  2. Once you see the "type something" prompt, enter a string and press enter. Note the output.
  3. Repeat for the second attempt.

What did you expect to see?

The output from the second session is exactly what I entered on the keyboard.

What did you see instead?

The output from the second session is missing the first character. If I add more executions of runTest(), I see the same effect in all but the first session.

For instance, in the session below I typed "hi" both times, but the second time only the "i" was registered:

Type something: hi
0000000   h   i  nl
         68  69  0a
0000003
Type something: i
0000000   i  nl
         69  0a
0000002

I tried a few things to no avail:

  • Discard bytes from stdin before and after the session (with bufio.NewReader().Discard()).
  • Different TerminalMode settings.
  • Calling os.Stdin.Sync() and os.Stdin.Seek(0, 2)
  • Execute reset locally before the SSH session.
  • etc.

I also tried a couple different versions of the SSH code in the snippet, and always got the same result. I was unable to reproduce this with a local shell, or with the ssh command-line tool (OpenSSH).

@gopherbot gopherbot added this to the Unreleased milestone Sep 15, 2020
@toothrot
Copy link
Contributor

/cc @FiloSottile @hanwen

@toothrot toothrot added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 15, 2020
@hanwen
Copy link
Contributor

hanwen commented Nov 16, 2020

can you reproduce this if you don't use the ssh/terminal package?

@jkohen
Copy link
Contributor Author

jkohen commented Nov 16, 2020

@hanwen How do you mean? If I remove the terminal.MakeRaw call or the entire block protected by terminal.IsTerminal, then I still see a similar bug, though it manifests slightly differently: I need to press enter one more time between runs of sshTest. I'm not an expert in terminals, but I think the enter is the only acceptable "separator" because the terminal is no longer in raw mode.

Without extra enter:

Type something: hi
0000000   h   i  nl
         68  69  0a
0000003
Type something: hi

0000000  nl
         0a
0000001

With an extra enter before the second "hi":

Type something: hi
0000000   h   i  nl
         68  69  0a
0000003
Type something:
hi
0000000   h   i  nl
         68  69  0a
0000003

In the end, I need everything in the current version:

  • I need to make the terminal raw to ensure that passwords aren't visible. In the default mode the terminal will echo passwords.
  • I need to request a PTY or else many applications in the remote system fail to request a password because they assume they are not in interactive mode.

The same workflow works perfectly with the OpenSSH client, as far as I can come close to reproduce this.

@hanwen
Copy link
Contributor

hanwen commented Nov 16, 2020

the question is whether the SSH package swallows a byte somewhere at the transport level (unlikely), or if there is a problem with the terminal layering that runs on top of the SSH package.

@jkohen
Copy link
Contributor Author

jkohen commented Nov 16, 2020

As per my last comment, I believe I was able to reproduce a variation of the bug without using the terminal module. This is the code I used: xcrypto-noterm-bug.txt

@silviucm
Copy link

@jkohen @hanwen
I posted a "working" / not-working scenario here:
https://play.golang.org/p/mK1UJ-BNMkV
In case it helps debugging this one.
The only way I made it "work" is by opening an alternate /dev/stdin *os.File, then close it at each iteration. The terminal still initializes with the os.Stdin fd 0 assumption though.

@cybertramp
Copy link

cybertramp commented Dec 7, 2022

Hi!
I'm making an SSH shell manager program, but I'm facing the same problem. Is this issue still pending?
Is there any other way to open stdin through a path on the Linux filesystem?

My symptoms are: If input after connecting with ssh shell(), the key is randomly chewed(swallowed).

I'd like to know how to fix it, but there is only one reference here related to the issue. 😥

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

6 participants