Powershell: feature-request: New-PSSession -HostName should be able to use the system's ssh-agent to get the required keys.

[AmandaCameron]

It'd be nice if we could use SSH PSRemote sessions with our configured session ssh-agent-compatible daemon to get the required security information/

For instance, I use gpg-agent to store my SSH private key securely on my Yubikey 4, as a result my key doesn't actually exist on my laptop.

From looking at the output of ps while New-PSSession is run, it appears you guys are shelling out to ssh anyway, and the ssh client supports the ssh-agent by default, so I assume something is being done to disable it for the invocation.

[iSazonov]

/cc @PaulHigin Could you please comment the feature request.

[PaulHigin]

The idea is to let SSH handle the connection/transport for PS remoting. I don't know what the mechanism is for SSH to work with ssh-agent but PowerShell shouldn't get in the way. More details and repro steps can help determine if PowerShell is preventing this. We may have to update PowerShell code to support this, if possible.

[AmandaCameron]

A quick test just confirmed what I thought might be the issue -- the
environment variables are being stripped by the time ssh is shelled out
to.

ssh uses the environment variable SSH_AUTH_SOCK to know where the unix
socket for the ssh-agent is, so at least that needs to be preserved.

I tested this with the following shell script placed in my $PATH before the
normal location of ssh:

#!/bin/sh

env >/tmp/test-ssh.env
exec /usr/bin/ssh "$@"

[PaulHigin]

Yes, this looks like a bug in PowerShell when forking the ssh process. It is passing in an empty string array for the environment variables.

https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/engine/remoting/common/RunspaceConnectionInfo.cs#L2148

I'll change this to a bug issue.

[AmandaCameron]

Any chance this can be bumped into 6.1.0? It's somewhat inconvient to be unable to use my securely-stored private key, instead having to use a password.

[PaulHigin]

• @SteveL-MSFT Adding Steve for priority question. I believe the fix would be fairly straightforward.

[SteveL-MSFT]

@AmandaCameron 6.1.0-Consider means we're considering it for 6.1.0 already

I know @PaulHigin is currently busy with some other work, but this seems like something that shouldn't be too complicated to fix, so I'll leave it to Paul to address when he's able to

[PaulHigin]

Ok, I'll look at a fix for 6.1.0 timeframe.

[PaulHigin]

@AmandaCameron This should fix the problem. Please try your scenario with a build having this change.

[AmandaCameron]

Will there be another preview release before the full release? If so I'll report back when I see that update hit my laptop apt repo.

[PaulHigin]

@AmandaCameron Yes, there will be another preview release probably the first week of July. However, you can also pick up a nightly build that runs side-by-side to do a quick verification.

[AmandaCameron]

I'm having some trouble finding a non-docker binary release of the nightly builds, so I'll double-check that this is def. fixed for my usecase in early july.

[SteveL-MSFT]

iex "& { $(irm https://aka.ms/install-pscore ) } -Daily"

Run from PowerShell should install the latest successful nightly build

[AmandaCameron]

Assuming the latest daily is including this fix, it doesn't appear to be fixed. The environment contains a PWD entry now, but not the required SSH_AUTH_SOCK one.

EDIT: If I type $env:SSH_AUTH_SOCK in the shell, I get the expected value of /run/user/1000/gnupg/S.gpg-agent.ssh

[PaulHigin]

Does the parent process have the SSH_AUTH_SOCK environment variable set? When creating the SSH process for the remote connection, all parent process environment variables are now copied to the new child SSH process. The assumption is that the parent process has all needed environment variables.

[rkeithhill]

BTW if you are using the ssh-agent service from the OpenSSH that ships with Windows 10 1803, none of the SSH_AUTH env vars are defined in any process AFAICT. Yet I use this with Git and it has no problems connecting/pulling/pushing to repos using SSH and my passphrase protected key (served up by ssh-agent).

Just want to make sure that PowerShell Core SSH remoting works with the ssh-agent that comes from the PowerShell project on GitHub. :-)

[AmandaCameron]

@PaulHigin I'm not sure what you mean by "parent process" I mentioned in an edit above that at the very least the powershell commandline knows of the auth socket, through $env:SSH_AUTH_SOCK -- the only env variable that my test script above is showing is PWD which is pointed to the directory containing the test ssh command script

[AmandaCameron]

I just checked the code, and while I'm not that familiar with C# -- this looks like where the startInfo is coming from? I'm not sure why that would have it's own copy of the parent's environment.

[PaulHigin]

By parent process I mean the command line PowerShell process you are using to create a remote session. I assumed that the default StartInfo environment variables were obtained from the process in which it is currently running. My limited testing seemed to indicate that this was so, but maybe not since your $env:SSH_AUTH_SOCK setting doesn't seem to be propagating. I'll need to take a closer look.

[PaulHigin]

I found some time to look at this some more and I can verify that StartInfo does indeed contain the parent process environment variables, including SSH_AUTH_SOCK, and that they are being passed into the ssh process used for the connection and transport. So there must be something else that prevents ssh-agent from working.

I'll play around with ssh-agent to see if I can repro the problem.

[rkeithhill]

I'm confused about something here. The ssh-agent that comes with Git for Windows will create/use those env vars. But AFAICT, the ssh-agent that comes with OpenSSH (Windows 10 1803), it doesn't create or need those env vars.

[AmandaCameron]

Worth noting -- I'm running an Ubuntu-based laptop, not Windows where I'm encountering the issue.

The steps I listed above to dump the environment variables was showing only PWD with the latest change.

[PaulHigin]

I verified that the ssh process created by PowerShell remoting does not have the environment variables, by looking at the virtual file location /proc/[procid]/environ. It seems that our process creation code is not passing in the environment information correctly. I look deeper when I get some time.

[PaulHigin]

My apologies. I was testing the old build without my fix and this is why I didn't see any environment variables. When I test a build with my fix I do now see the environment variables in the ssh process, including SSH_AUTH_SOCK. Next I'll see if I can get ssh-agent working.

[AmandaCameron]

Okay, I just re-ran the powershell daily download just now, and when
testing I wasn't asked for my password when sshing into something, so I
expect that I juts managed to get an older nightly when I installed it
earlier? Appologies for the false alarm on it being broken still. :\

On Thu, Jul 12, 2018 at 2:37 PM Paul Higinbotham [e-mail]
wrote:

My apologies. I was testing the old build without my fix and this is why I
didn't see any environment variables. When I test a build with my fix I do
now see the environment variables in the ssh process, including
SSH_AUTH_SOCK. Next I'll see if I can get ssh-agent working.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/PowerShell/issues/6207#issuecomment-404609326,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAG_ztvgjwvi04CY-dE2z_viEoSGOCp7ks5uF5dZgaJpZM4SN8Ps
.

[PaulHigin]

No problem. It looks like you did the same thing I did and tested on an older build. Glad to know it is working.