Change in handling of IdentityAgent configuration between 8.6 and 8.9

[3b0b]

I use this fork of Krypton to get a Windows build; it's been fine as provided until now.

After updating to OpenSSH 8.9.1 (which I think actually came through with the latest Windows 11 Insider build) krssh was no longer working for me. After rolling Windows back and installing from the MSI and running some tests, I've concluded that the problem is that with the IdentityAgent set the way Krypton configures it:

IdentityAgent \\.\pipe\krd-agent

in 8.9.1 there is an error which didn't occur in 8.6; details below.

Either changing all the backslashes in that config line to forward slashes, or leaving that line out and setting $env:SSH_AUTH_SOCK to that value instead (with any combination of slashes I tried), seems to fix the problem.

I'm not sure whether that means there is some kind of new bug in parsing/handling that setting or if it should have required forward slashes all along and the handling has actually been fixed. In case it's the former, and in case it might help anyone else, I thought I should report it even though I seem to have found a fix/workaround.

"OpenSSH for Windows" version
8.9.1.0

Server OperatingSystem
Any

Client OperatingSystem
Windows 11 Insider

What is failing
krd-agent

Expected output
(from ssh -v in OpenSSH 8.6)

debug1: Will attempt key: RSA SHA256: agent

Actual output
(from ssh -vvv in OpenSSH 8.9.1)

debug3: unable to connect to pipe \.\pipe\krd-agent, error: 3
debug1: get_agent_identities: ssh_get_authentication_socket: The socket is not connected

Note: ssh -vv or ssh -v results in the following instead

debug1: get_agent_identities: ssh_get_authentication_socket: No such file or directory

./.ssh/config excerpt

Host *
    IdentityAgent \\.\pipe\krd-agent
    ProxyCommand path\to\krssh.exe %h %p

Fixed with:

Host *
    IdentityAgent //./pipe/krd-agent
    ProxyCommand path\to\krssh.exe %h %p

[vbrozik]

I can confirm this incompatible change. I have encountered it too.

I had this setting in my multi-platform ~/.ssh/config:

Match !exec "uname -o | grep -qE 'Linux|Msys|Cygwin'"
    IdentityAgent \\.\pipe\openssh-ssh-agent

The backslashes stopped working (when going from the standard OpenSSH to the beta version on Windows 10):

PS> ssh -vvv ...
OpenSSH_for_Windows_8.9p1, LibreSSL 3.4.3
...
debug3: unable to connect to pipe \\.\\pipe\\openssh-ssh-agent, error: 3
debug1: get_agent_identities: ssh_get_authentication_socket: No such file or directory
...

When using normal slashes, it works again:

PS> ssh -vvv -o IdentityAgent=//./pipe/openssh-ssh-agent ...
...
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: agent returned 2 keys
debug1: Will attempt key: rsa-key-... agent
...

Escaping the backslashes by doubling them works too:

Match !exec "uname -o | grep -qE 'Linux|Msys|Cygwin'"
    IdentityAgent \\\\.\\pipe\\openssh-ssh-agent

So maybe it is not a change in the Windows fork of OpenSSH but in the way the original OpenSSH handles backslashes.

[OperativeThunny]

I am also having this issue, however my problem is with PuTTY's Pageant. I have spent a very long time trying to figure this out. After I switched my windows build from the general release branch to the insider build all my development workflows stopped functioning because the windows OpenSSH ssh.exe client would no longer pick up the keys that were loaded in pageant, when it had worked previously with no issue. I can also confirm that the solution of changing the back slashes to forward slashes solves the problem.

However that introduces another complexity because the way I start pageant is with the --openssh-config option using a windows shortcut in the shell:startup folder (win+R shell:startup is a fast way to get there). This command line flag passed to pageant creates an openssh config file fragment that specifies the IdentityAgent line, and that config file fragment is included in my $env:USERPROFILE.ssh\config file. So the fact that back slashes now need escaping or conversion to forward slashes is an issue because pageant does not do that. So, I will have to make a script to automatically change the slashes.

This is what is in my startup shortcut:

"C:\Program Files\PuTTY\pageant.exe" --openssh-config %USERPROFILE%\.ssh\pageant.conf C:\PathToKey1.ppk C:\PathToKey2.ppk C:\PathToKey3.ppk 

With this updated SSH from the windows insider program (Dev Channel) I was getting the following errors:

> ssh -vvv HOSTNAME
OpenSSH_for_Windows_9.2p1, LibreSSL 3.6.2
debug1: Reading configuration data C:\\Users\\user/.ssh/config
debug3: C:\\Users\\user/.ssh/config line 4: Including file C:/Users/user/.ssh/pageant.conf depth 0
debug1: Reading configuration data C:/Users/user/.ssh/pageant.conf
...
debug3: ssh_get_authentication_socket_path: path '\\.\\pipe\\pageant.user.aa4994a6a45292abe6535a1abef77f20ce2922e94d9e9c7288712d4fa85c5afa'
debug3: unable to connect to pipe \\.\\pipe\\pageant.user.aa4994a6a45292abe6535a1abef77f20ce2922e94d9e9c7288712d4fa85c5afa, error: 3
debug1: get_agent_identities: ssh_get_authentication_socket: No such file or directory

If I then manually changed the file that pageant generated to have forward slashes it worked:

debug3: ssh_get_authentication_socket_path: path '//./pipe/pageant.user.aa4994a6a45292abe6535a1abef77f20ce2922e94d9e9c7288712d4fa85c5afa'
debug2: get_agent_identities: ssh_agent_bind_hostkey: agent refused operation
debug1: get_agent_identities: agent returned 3 keys

Then, if I then manually changed the file that pageant generated to have escaped back slashes, it also worked:

debug3: ssh_get_authentication_socket_path: path '\\\\.\\pipe\\pageant.user.aa4994a6a45292abe6535a1abef77f20ce2922e94d9e9c7288712d4fa85c5afa'
debug2: get_agent_identities: ssh_agent_bind_hostkey: agent refused operation
debug1: get_agent_identities: agent returned 3 keys

An alternative solution that does not involve slash conversion is to set the $env:SSH_AUTH_SOCK environment variable to the pageant named pipe in powershell:

set-item -Path "ENV:\SSH_AUTH_SOCK" -Value "$((Get-ChildItem -Path \\.\pipe\ -Recurse -Filter *pageant*)[0].FullName)"

You can see the value set by the command like this:

PS C:\> set-item -Path "ENV:\SSH_AUTH_SOCK" -Value "$((Get-ChildItem -Path \\.\pipe\ -Recurse -Filter *pageant*)[0].FullName)"
PS C:\> Get-Item -Path "ENV:\SSH_AUTH_SOCK"

Name                           Value
----                           -----
SSH_AUTH_SOCK                  \\.\pipe\pageant.user.aa4994a6a45292abe6535a1abef77f20ce2922e94d9e9c7288712d4fa85c5afa

PS C:\>

Then a subsequent invocation of ssh would succeed (note how this output shows escaped back slashes, where the above powershell command does not produce escaped slashes):

debug3: ssh_get_authentication_socket_path: path '\\\\.\\pipe\\pageant.user.aa4994a6a45292abe6535a1abef77f20ce2922e94d9e9c7288712d4fa85c5afa'
debug2: get_agent_identities: ssh_agent_bind_hostkey: agent refused operation
debug1: get_agent_identities: agent returned 3 keys

However, in order for the environment variable to be used to pass the correct windows named pipe to the Windows OpenSSH ssh.exe, there can be no mention of IdentityAgent in any parts of the config files.

I am going to opt for using the environment variable approach so I dont have to run a script on every login to fix the pageant generated config file. For anybody else that wants to do this by setting a persistent user scoped environment variable, here is the powershell magical incantation to do so, assuming you have pageant running so the named pipe actually exists:

[System.Environment]::SetEnvironmentVariable("SSH_AUTH_SOCK", "$((Get-ChildItem -Path \\.\pipe\ -Recurse -Filter *pageant*)[0].FullName)", "User")

Based on reading elsewhere I believe that should be OK because in theory the named pipe is supposed to give the same name for the same user across executions.

[maffe]

My ssh suddenly stopped using the keys from Pageant. I updated Pageant from 0.78 to 0.81, now (actually since 0.79) it puts forward slashes in the configuration file and the keys loaded in Pageant are picked up again. This is probably the safest method and I think other programs should use forward slashes as well.