-
Notifications
You must be signed in to change notification settings - Fork 471
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
fix(ec2): give warning when OpenSSH client is outdated. #6018
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
} | ||
|
||
function parseSshVersion(output: string): string | undefined { | ||
const match = output.match(/OpenSSH_(\d+)\.(\d+)/) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of all this, could we we just triy to connect to the remote and surface any error messages (plus ssh version) on failure? We already do that for the "terminal" feature, right? So for vscode, we could do that as a pre-step, to really check that things are working.
An extra benefit is that this gives a much better experience if there is an ssh issue, compared to checking vscode-remote's ssh window.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The error is coming from the connect script, i.e. the child process that launches the new instance of VSCode so I am not sure how to surface it. Especially since the child process is successfully opening VSCode, but then the newly opened VSCode instance throws an error. We would have to route that error back to this instance of VSCode somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, when we invoke code
with a remote URL, vscode invokes ssh
implicitly for us. But what I'm thinking is that we can manually invoke ssh
ourselves, before invoking code
, and just run a trivial command on the remote like sh -c 'true'
. That gives a true picture of whether ssh can work.
If that fails, we can report/log the ssh output and that gives us valuable troubleshooting info. Without needing to check for specific ssh versions. This is also future-proof for any changes we make to our .ssh/config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahhh, I see. That's a good idea. I'll work on that in a fresh PR and link it here.
Moved to #6037 |
## Problem Follow up to #6018 (comment) ## Solution - Run `ssh` within the same env as it will be run on real connection. - Log any resulting errors, and inform user where the process failed. - Also part of this PR is moving some functions to `remoteSession.ts` that are general enough to be there. Error msg: <img width="1518" alt="Screenshot 2024-11-15 at 5 53 51 PM" src="https://github.com/user-attachments/assets/e8e56887-b792-43e3-9d94-73d0e5246766"> --- <!--- REMINDER: Ensure that your PR meets the guidelines in CONTRIBUTING.md --> License: I confirm that my contribution is made under the terms of the Apache 2.0 license. --------- Co-authored-by: Justin M. Keyes <[email protected]>
Problem
See #6015
Solution
Logs + Error:
(Ignore version number)
Notes
Believe test failures are unrelated as they are currently on master. pending fix.
License: I confirm that my contribution is made under the terms of the Apache 2.0 license.