[Windows] WSL integration possible using some extra tools

Hey there, @klinteastwood,

You're correct that in theory forwarding the pipe should also allow the op tool in WSL to unlock with the help of 1Password for Windows 8. Today, the CLI attempts to connect to a UNIX socket called 1Password-BrowserSupport.sock in either $XDG_RUNTIME_DIR if its available, or in /run/user/$UID if the first doesn't exist.

The named pipe you found is used by both the CLI and 1Password in the Browser, but since the browser extension used it first it has an under-loaded name. However, I should note that even if this does end up working for you today, there's no guarantee something in this process won't change down the road.

Hopefully that helps you out!

Hi,

I have forwarded the ssh-agent like teh_c helped explain in this topic. Thanks a lot, it works like a charm!

Moving on, I would like to do the same with regards to the biometric unlock feature of the 1Password CLI. I have the Windows 1Password app and the linux (wsl) 1Password CLI.
If I understand it correctly, the documentation states that the biometric unlock feature is enabled in Windows by the app opening a named pipe and the CLI connecting to it. It also states that it is enabled in Linux in the same way, but with a Unix socket instead.
Documentation: https://developer.1password.com/docs/cli/biometric-security#how-does-1password-cli-communicate-with-the-1password-app

If I understand the socat and npiperelay solution correctly, it basically plants a Unix socket, which is forwarded to a Windows named pipe. As such, the same kind of solution should be possible to enable the CLI biometric unlock in WSL with Windows 1Password as the backbone. Right?

Unfortunately I cannot figure out which Unix socket the linux CLI attempts to access, nor the named pipe which the 1Password app opens. I have verified that the biometric unlock works with the windows CLI, so the names pipe must be there somewhere.
I can find one Unix socket which seems related to 1Password ($HOME/.config/op/op-daemon.sock) but I am assuming that is opened by the CLI. (using 'ss -a' to find sockets)
I can find one named pipe which seems releated to 1Password (\.\pipe\1Password-1-1Password-BrowserSupport) but that seems to be targetted towards the browser extensions. (using '[System.IO.Directory]::GetFiles("\.\pipe\")' to find named pipes)

Would it be possible for you to share some additional details regarding the Unix sockets and named pipes in play ag_Christian ? :)

I use the Remote-WSL extension (but not Remote-SSH) in VSCode on Windows 11 and got the error fatal: cannot run C:/Windows/System32/OpenSSH/ssh.exe: No such file or directory when trying to use git in a WSL folder. This was fixed by setting export GIT_SSH_COMMAND=/usr/bin/ssh in .bashrc and it now works with 1Password's SSH agent.

Thanks for the reply, I cleared out the IndentityAgent line from the config and went through the setup guide again, and noticed "Windows Hello" was a requirement to get it to work in the first place, so with this configured, its now working properly both from Powershell and from within WSL2 (Ubuntu). Awesome.

Hi @henriksoederlund,
No need for any particular info on ~/.ssh/config.

Indeed, I've removed that file from a particular WSL and got it running; in my case, it took a while because socat didn't want to be installed.
Just make sure that you can invoke npiperelay.exe from within WSL, as well as socat and it should work like a charm.

I couldn't get this to work I'm afraid (WSL2). How should I modify my ~/.ssh/config file to make this work, do I need to add something like this? Grateful for any tips!

Host *
IdentityAgent ~/.1password/agent.sock


This is great news, thanks ag_Christian!

I found the existing process checking a bit elaborate and am just using the single line version in .bashrc as the "already running" error message doesn't bother me:

export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock
socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork

Hey everyone, thanks for the feedback so far,

We have plans to bring support for Windows Unix Domain Sockets to the built-in SSH agent in the future to complement the existing Microsoft OpenSSH named pipe support. This should allow the agent to communicate with WSL processes and other Windows apps such as the Git Bash tool suite that are not Microsoft SSH aware.

Would be great improvement.

Thanks for this tip. It worked great on WSL2. Does 1Password have any plans to simplify the pipe to socket mapping in WSL?