-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
Can't use SSH with Powershell #4682
Comments
windows settings > apps > apps & features > optional features > add a feature > openssh client |
This sounds a lot like x86/x64/System32/SysWOW trickery. @kuzi-moto do you know what architecture you're running on your PC? This sounds a lot like how when I run Terminal from VS after building it, it can't find WSL on the path (because it's not 32-bit), but running it normally, WSL works fine. Are you running something like: or
|
Looks like my standard PowerShell prompt runs from |
That's really unusual. From inside WT, can you also share |
|
If you run it from WT as |
Yes, that does appear to work. |
This is fascinating. Everything we're seeing from your system (through WT) is acting as though you're in WoW/using powershell x86 on an x64 machine/possibly on an ARM64 machine where it doesn't ship arm64 powershell by default. Did you install Terminal from the store, or from our downloads page? Can you share your profiles.json and the defaults.json from your terminal distribution? Would you also mind sharing the output of Sorry for all the questions! |
I initially installed it via chocolatey a while ago. On seeing these issues I uninstalled it, then re-installed via the store.
profiles.json
defaults.json
No problem! |
So, I've been thinking about this for a while, and I just can't dig up a single idea as to why it's happening. Would you mind running Process Monitor? If you create a filter for filterfiles onlyssh filter, possibly:I'd love to see what powershell is doing when you try to run When I run it, I get this: it shows powershell searching for ssh in |
I'm not sure what's wrong, but I get a bit over 2,000 events when running Here is a screenshot of the filters: I have uploaded a spreadsheet of the results for your perusal: Logfile.xlsx |
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. |
Here you go: Logfile.xlsx |
I've got really great and terrible news for you. You have a stray copy of |
Closing as a question -- root caused to powershell living somewhere it shouldn't, still on $PATH. Fix by identifying why that powershell's there (and removing it) or changing the commandline of Windows PowerShell so that it points to the one living in System32\WindowsPowerShell\v1.0 😄 |
Hey @kuzi-moto -- did you ever end up figuring out where that copy of PowerShell came from? 😄 |
Occasionally, we get users with corrupt PATH environment variables: they can't lauch PowerShell, because for some reason it's dropped off their PATH. We also get users who have stray applications named `powershell.exe` just lying around in random system directories. We can combat both of these issues by simply hardcoding where we expect PowerShell and CMD to live. %SystemRoot% was chosen over %WINDIR% because apparently (according to Stack Overflow), SystemPath is read-only and WINDIR isn't. Refs #6039, #4390, #4228, #4682 (stray powershell.exe). This may impact #6082 (as it might be another "stray file" incident).
Actually I never did! Couldn't figure out how it got there, so I think I just deleted it and all was well. |
Excellent. I thought of you because of #6684 -- I can't believe it took me literally six months to think of this solution ;P |
Well, hindsight is always 20/20! I'm just glad I got it working, been happy using it this far. |
Occasionally, we get users with corrupt PATH environment variables: they can't lauch PowerShell, because for some reason it's dropped off their PATH. We also get users who have stray applications named `powershell.exe` just lying around in random system directories. We can combat both of these issues by simply hardcoding where we expect PowerShell and CMD to live. %SystemRoot% was chosen over %WINDIR% because apparently (according to Stack Overflow), SystemPath is read-only and WINDIR isn't. Refs #6039, #4390, #4228 (powershell was not found) Refs #4682, Fixes #6082 (stray powershell.exe)
Occasionally, we get users with corrupt PATH environment variables: they can't lauch PowerShell, because for some reason it's dropped off their PATH. We also get users who have stray applications named `powershell.exe` just lying around in random system directories. We can combat both of these issues by simply hardcoding where we expect PowerShell and CMD to live. %SystemRoot% was chosen over %WINDIR% because apparently (according to Stack Overflow), SystemPath is read-only and WINDIR isn't. Refs #6039, #4390, #4228 (powershell was not found) Refs #4682, Fixes #6082 (stray powershell.exe) (cherry picked from commit 2fc1ef0)
Occasionally, we get users with corrupt PATH environment variables: they can't lauch PowerShell, because for some reason it's dropped off their PATH. We also get users who have stray applications named `powershell.exe` just lying around in random system directories. We can combat both of these issues by simply hardcoding where we expect PowerShell and CMD to live. %SystemRoot% was chosen over %WINDIR% because apparently (according to Stack Overflow), SystemPath is read-only and WINDIR isn't. Refs #6039, #4390, #4228 (powershell was not found) Refs #4682, Fixes #6082 (stray powershell.exe) (cherry picked from commit 2fc1ef0)
This comment has been minimized.
This comment has been minimized.
Probably don't do that, just use the system's built-in SSH client once you figure out which architecture you're on. |
Environment
Steps to reproduce
ssh
Expected behavior
Actual behavior
Additional Information
Something that's interesting, is that I can't even view the OpenSSH directory...
But when using a normal PowerShell prompt, works just fine:
The text was updated successfully, but these errors were encountered: