Win32-OpenSSH
Win32-OpenSSH copied to clipboard
OpenSSH refusing to work on Local Account; works fine on Admin Account
Prerequisites
- [x] Write a descriptive title.
- [x] Make sure you are able to repro it on the latest version
- [x] Search the existing issues.
Steps to reproduce
I'm experiencing trouble in getting SSH to work on my local user account. OpenSSH has been installed on the admin side both via the Optional Features and following the instructions on the repo here for the msi file installation. Get-Service -Name *ssh does return that the sshd and ssh-agent are running, but I'm still unable to call ssh on **BOTH **** Powershells in either local or elevated modes. I've never had issues with SSH Keygen before, and I can sure use some advice on how to get this to work.
System Specs: Windows 10 Pro, Intel Core i7 11th Gen.
Expected behavior
ssh keygen asks to create file for rsa_id
Actual behavior
ssh does not exist
Error details
ssh : The term 'ssh' is not recognized as the name of a cmdlet, function, script file, or
operable program. Check the spelling of the name, or if a path was included, verify that the
path is correct and try again.
At line:1 char:1
+ ssh
+ ~~~
+ CategoryInfo : ObjectNotFound: (ssh:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
Environment data
Name Value
---- -----
PSVersion 5.1.19041.5737
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.19041.5737
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Version
5.1
Visuals
No response
ssh-keygen is being called but the error is message is ssh not found? I would expect it to be ssh-keygen not found, unless there's some unexpected shell parsing with - characters?
Anyway, I suggest verifying that the ssh / ssh-keygen binaries are located in one of the following locations:
$env:SystemDrive\Windows\System32\OpenSSH(optional feature install location)$env:ProgramFiles\OpenSSH(MSI install location)
If the binaries are in either of the expected locations, can you also check that the location is in the $env:PATH variable or try calling ssh-keygen with the full path to the binary?
Another thing to check after re-reading this - does the local user have execute permissions on the ssh files installed to either location?