-
Notifications
You must be signed in to change notification settings - Fork 67
Wsl2 / Windows 11 Extremely slow agent communication times #24
Comments
I have no win 11 on any device actual but @tobiaskohlbau. Can you confirm this behavior? |
I did not experience this on my machine running the latest insider build. By any chance this only happens on the first try? Thats most likely caused by the gpg-connect-agent not launched and needed to be relaunched. |
Nope, seems to happen everytime. I originally came here to complain it was taking over a minute, but that was actually my issue to do with running ssh-add too many times in a bash script. However the above 20s were based on runing ssh/ssh-agent directly. Any debug I can run? edit |
Can you try and run the attached utility program either by the provided binary or the attached sourcecode? It tries to find the pageant window and prints it's window handle. main.go package main
import (
"fmt"
"syscall"
"github.com/lxn/win"
)
func main() {
hwnd := win.FindWindow(syscall.StringToUTF16Ptr("Pageant"), syscall.StringToUTF16Ptr("Pageant"))
fmt.Println(hwnd)
} go.mod
|
Pretty much immediate in windows, reasonably quick from linux (i'd slay a fraction slower) |
Sorry for the late response. I'm still nowhere near an idea why this happens to you. That beeing a little bit slower on linux is most likely caused by the interop layer in WSL. I'm using the gpg-agent with putty support as well on my Windows 11 machine. Is your machine an updated one or a clean install? Maybe it's only happening if it's a clean install. |
@tobiaskohlbau So i've just done another clean install on another laptop and have exactly the same issue, so this might be a clean install thing?
|
Also of note, I tried opening pageant to see if that was any quicker, it;s definitely faster, but still taking 10s for an Pageant
GPG
|
Adding in another data point:
|
Thanks for all the datapoints. With the upcoming release of Windows 11 I think it's worth digging into this. I'm still not experiencing this in my setup. Just out of curiosity do you all have:
enabled, so that every request must be confirmed by a press on the yubikey? Maybe that is causing this issue, as I've not enabled that for now. Will test my theory on the next weekend. |
No, I do not have to confirm the request. |
I am experiencing the same thing as to slowness. initialization script being used for this:
Yubikey settings:
pageant-check.exe:
ssh-add -L while tailing agent logs:
gpg --card-status while tailing agent logs:
On that one, please note the 20 second difference between the log showing "Starting exe" and output actually showing for the card-status command. I'm going to see if I can revert to an earlier release of socat in case that is an issue. |
Running ubuntu 20.04 (Focal) and the release of socat is 1.7.3.3-2 which was released on 20 Feb 2020 and it doesn't look like there's any previous release to try in Focal. Also: Pegged CPU may be due to trying to run ssh via git through WSL2 vscode integration. I'm gonna mess with it a bit to see if anything pops up in the log. |
I do have touch to flash enabled, however the ssh-add/list exchange still takes 8s on my current setup without a key even in the system Also, thanks for looking into this! |
Enabling verbose logging on socat and tailing both socat and wsl2-ssh-pageant logs:
I'll see if I can find output for the GPG4WIN agent. |
I'm not finding the gpg4win log output (cursory glance as it was), but after messing for a bit, I think you're onto something with the win.FindWindow call. |
To add some more info from a setup not affected by this issue (maybe it helps): I couldn't get my YubiKey to work at all on Win 11 with the GnuPG 2.2.28 thats bundled with Gpg4win ( Did a clean install with the first released insider beta ISO:
gpg-agent.conf:
tested on https://github.com/yuk7/ArchWSL:
|
F***g unbelievable! Pardon my French!! So in the script given in
to
|
I hate that you found this. I can confirm that I'm getting consistent 5 second times running pageant-check in the prescribed fashion. This is strictly an issue with the library that the author is using, and not any issues with the application itself. This is a frustrating bug. I may submit this as a bug on the underlying library, but the author hasn't touched the source on it since March so I doubt that it's going to be worked on and fixed for Win 11.
Further testing proved your fix to work. I'm doing this over remote desktop with a Yubikey 5 NFC and as soon as I copied the executable to the prescribed destination and made the change to the script, my attempt to ssh was successful without having to wait half a minute. Good job figuring this out. You just made WSL2 usable for me. |
I have my doubts that it's the underlying library. As it's executed on Windows in both cases. The only thing which changes is the initialization done by WSL or Microsoft to name it. It think it's time to report this issue to the upstream WSL. There was a very similar found with the new Store WSL version which wasn't able to execute from within the Linux filesystem at all. See #27 and microsoft/WSL#7521. Maybe it's related and the people at Microsoft have an idea what's happening. I'm still curious why others and me are not experiencing this. Maybe there is still something common in your setups. If you open an issue on wsl please reference this issue and microsoft/WSL#7521 so that they get as most information as possible. Edit: Great find @ophers many thanks! |
I mean that it's not your app, but the FindWindow function from the lxn/win library that is having the difficulty. Whether it's something that has changed in functionality or a bug within WSLg, it's nothing you're able to really do anything about. |
Just to clarify, I didn't want to say it's not wsl2-ssh-pageant nor lxn/win. But I doubt that it's related to lxn/win as this is only a wrapper around the windows functions (syscalls). The library doesn't know anything about WSL or other linux related things. And it's never executed in Linux context neither, it's just called from the interop functionality of the WSL (which MS is responsible for). All lxn/win is doing is calling the following on the windows provided system libraries:
https://github.com/lxn/win/blob/a377121e959e22055dd01ed4bb2383e5bd02c238/user32.go#L2440-L2447 I will go ahead and report the issue to microsoft/wsl. |
Everyone who is subscribed to this issue and experiencing it please go to the following issue microsoft/WSL#7591 and try to describe your WSL setup, windows version and as much as possible to help Microsoft developers recreate the situation.
|
Done. |
@tobiaskohlbau moving the exe back to windows fixes, well done all! Interestingly a symlink from the linux FS to the windows file system also works to keep configs more comparable |
Done that. I also have Docker Desktop 3.6 installed. Maybe this is a differentiating factor? |
It might have nothing to do with |
Clarify the install procedure for windows 11, This could "resolve" BlackReloaded#24 Once microsoft/WSL#7591 is fixed this could be reverted
So I've been using this for a long time on windows 10 and have had absolutely no issues, well done for a really awesome piece of software.
However, since upgrading my laptop to windows 11 and reinstalling WSL2 (with WLSg if that makes a difference) the communication to the agent is EXTREMELY slow. From typing ssh at the command line to actually getting the gpg pincode prompt (/touch to auth flash on my yubikey) is taking over 20s,
ssh-add -L
is also taking a similar amount of time.Performing the same operation from windows connecting to the gpg agent and I get the prompt instantly from both putty and winssh, implying this is an issue with the WSL2 connection somewhere.
Any ideas?
The text was updated successfully, but these errors were encountered: