Skip to content

JetBrains Gateway 2022.2 RC doesn't work with Coder SSH #3125

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

Closed
spikecurtis opened this issue Jul 22, 2022 · 6 comments
Closed

JetBrains Gateway 2022.2 RC doesn't work with Coder SSH #3125

spikecurtis opened this issue Jul 22, 2022 · 6 comments
Assignees
Labels
api Area: HTTP API

Comments

@spikecurtis
Copy link
Contributor

Problem:

On Gateway 2022.2 RC, connecting to Coder over SSH hangs on detecting IDEs. Looking through the logs

idea.log

it appears that Gateway tests for the presence of an executable utility to find installed IDEs. This utility doesn't exist, but Gateway somehow concludes that is does. It then tries to execute this utility and fails.

Talking with JetBrains, their hypothesis is that our SSH server is not setting command return codes correctly when a PTY is allocated. Notes from Slack below:

Any chance something is overriding test shell builtin or unix utility on the host? Or some obscure SSH server setting results in all process exit codes being returned as 0?

Nikolay Kuznetsov
5 hours ago
Speaking of, is the SSH server some custom thing that is not OpenSSH?

Spike Curtis
45 minutes ago
It's our custom agent running https://github.com/gliderlabs/ssh

gliderlabs/ssh
Easy SSH servers in Golang
Website
https://godoc.org/github.com/gliderlabs/ssh
Stars
2628
Added by GitHub

Spike Curtis
38 minutes ago
test seems to be doing the right thing when I execute it through the regular ssh CLI:
spike@Codebook coder % ssh coder.dogfood test -f /home/coder/.cache/JetBrains/RemoteDev/remote-dev-worker/remote-dev-worker_8be48ed1f7d9d149a663842f0df2735b7433265d1654774596e54ce70af850f2
spike@Codebook coder % echo $?
1
spike@Codebook coder % ssh coder.dogfood test -f /home/coder/.cache/JetBrains/RemoteDev/remote-dev-worker/remote-dev-worker_7d32e4d2185f31ff477d51c73f533f4a312dfbd63132e75dc59ca2914b3965c4
spike@Codebook coder % echo $?
0

Nikolay Kuznetsov
18 minutes ago
Not sure if the repo you linked includes a default handler for "generic SSH server" use case. What if you specify -t or -T flags for ssh? Does that affect return value?

Spike Curtis
13 minutes ago
spike@Codebook coder % ssh -T coder.dogfood test -f /home/coder/.cache/JetBrains/RemoteDev/remote-dev-worker/remote-dev-worker_8be48ed1f7d9d149a663842f0df2735b7433265d1654774596e54ce70af850f2
spike@Codebook coder % echo $?
1
spike@Codebook coder % ssh -t coder.dogfood test -f /home/coder/.cache/JetBrains/RemoteDev/remote-dev-worker/remote-dev-worker_8be48ed1f7d9d149a663842f0df2735b7433265d1654774596e54ce70af850f2
Connection to coder.dogfood closed.
spike@Codebook coder % echo $?
0

Nikolay Kuznetsov
12 minutes ago
Found it I guess. By default Gateway requests a PTY for most commands to allow for SIGHUP-based process termination. Looks like your custom agent fails to properly handle exit codes in such cases.

Spike Curtis
< 1 minute ago
thanks for your help! I'll dig in some more on our side and see if I can sort this out

@spikecurtis
Copy link
Contributor Author

Ok, I've confirmed that with OpenSSH, it does correctly return the exit code when a PTY is requested:

spike@Codebook coder % ssh -t -p 2222 linuxserver.io@localhost test -f /not/a/real/file           
Connection to localhost closed.
spike@Codebook coder % echo $?                                                         
1

@fioan89
Copy link
Collaborator

fioan89 commented Jul 25, 2022

Not sure if it helps, but even if no PTY is requested, al exit codes above 1 are normalized to 1:

ssh -v coder.Ryland /home/coder/test_exit_code
OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, OpenSSL 1.1.1f  31 Mar 2020
............................................................
Authenticated to coder.ryland (via proxy).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: proc
debug1: Sending environment.
debug1: Sending env LANG = C.UTF-8
debug1: Sending command: /home/coder/test_exit_code
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 1860, received 1360 bytes, in 0.1 seconds
Bytes per second: sent 20329.3, received 14864.4
debug1: Exit status 1

where test_exit_code:

#!/bin/bash

exit 5

@bpmct bpmct mentioned this issue Jul 25, 2022
20 tasks
@catvec
Copy link

catvec commented Jul 25, 2022

it appears that Gateway tests for the presence of an executable utility to find installed IDEs. This utility doesn't exist, but Gateway somehow concludes that is does. It then tries to execute this utility and fails.

I have the same symptoms of the IDE list check failing with the same pattern in the logs. Additionally I looked on the workspace and there was no binary in the location Jetbrains Gateway thought it should exist.

Another little clue for this issue: When I set PS1="" on the Coder workspace Jetbrains Gateway is at least able to load the list of installed IDEs and even list the directory structure on the workspace. However when you select an install location Jetbrains Gateway says the location does not exist, even though you just selected it via a file selection dialog where Gateway knew the directory existed.

@misskniss
Copy link

@spikecurtis when you get through that bug you are working on, will you add your estimate to this retroactively?

@spikecurtis
Copy link
Contributor Author

I'm able to get this working with #3192 merged and

JetBrains Gateway 2022.2
Build #GW-222.3345.108, built on July 22, 2022
Runtime version: 17.0.3+7-b469.32 aarch64

as the client + our example gcp-linux template.

@catvec
Copy link

catvec commented Jul 27, 2022

That's awesome! Can't wait for the next release to try this out 🙌🏻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Area: HTTP API
Projects
None yet
Development

No branches or pull requests

4 participants