[Windows] WSL integration possible using some extra tools

Community Member
edited May 3 in SSH


Just a note to say that by using a few extra tools (the security implications I still need to understand, caveat emptor etc.), I was able to get the SSH integration working fantasically well in Windows Subsystem for Linux (WSL).

The tools use a couple of programs to expose named pipes as unix sockets in WSL, which the ssh-agent can then use to authenticate.

I used the steps outlined here https://stuartleeks.com/posts/wsl-ssh-key-forward-to-windows/ and added the script to my .bashrc file (don't paste random scripts from the Internet without knowing what they do, check this is right for you before using it, etc. etc. :))

Hope it helps someone somewhere... :)


1Password Version: 80600027
Extension Version: n/a
OS Version: Windows 11 22543.1000


  • LucentLucent
    Community Member

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

  • MaxRaabMaxRaab
    Community Member

    Would be great improvement.

  • 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.

  • LucentLucent
    Community Member

    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

  • henriksoederlundhenriksoederlund
    Community Member

    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
  • dmbuildmbuil
    Community Member

    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.

  • henriksoederlundhenriksoederlund
    Community Member

    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.

  • LucentLucent
    Community Member

    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.

  • klinteastwoodklinteastwood
    Community Member


    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 ? :)

  • ag_Christianag_Christian

    Team Member

    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!

  • ereere
    Community Member

    @ag_Christian is there any way to follow updates for this?

    We have plans to bring support for Windows Unix Domain Sockets to the built-in SSH agent

  • ag_Christianag_Christian

    Team Member

    Hey there, @ere,

    We're currently waiting on upstream support from one of the Rust libraries we use. Their tracking issue can be found here, on GitHub. If this stagnates for too long, we'll most likely consider a different option though. Assuming they add support for this, we will try to quickly push out a new 1Password version which takes advantage of it.

    Thanks for checking in with us on this feature!

  • jiroujirou
    Community Member
    edited August 13

    @ag_Christian Is there any update regarding 1Password CLI integration in WSL? I have tried manually forwarding the "//./pipe/1Password-1-1Password-BrowserSupport" from Windows to WSL using a combination of socat and npiperelay but the socket got forcibly closed. This is most likely due to the CLI security model explained here and the pipe was opened from an unauthenticated app (npiperelay).

    I also have tried using the Windows version of 1Password CLI running under WSL but it is plagued by this error making it very unreliable.

  • startcook1estartcook1e
    Community Member
    edited September 11

    Hey there,

    I've successfully added Github SSH via 1Password on cmd.exe, but fail to do so in WSL2 (ubuntu).
    I've followed the outlined steps:

    • npipereleay accessible from path in Windows
    • socat installed in WSL

    However, WSL doesn't get access to my keys in 1P. Can someone tell my what's wrong with this setup?

    $ ssh [email protected]:
    [email protected]: Permission denied (publickey).
    $ git pull:
    error: unsupported value for gpg.format: ssh
    fatal: bad config variable 'gpg.format' in file '/home/jannik/.gitconfig' at line 2

    When I remove the gpg.format = ssh in WSL, I get no error while pulling but still can't ssh to [email protected]

    My .gitconfig at "C:\Users\<user>\.gitconfig" and "~/.gitconfig" is the same:

        format = ssh
    [gpg "ssh"]
        program = C:\\Users\\<user>\\AppData\\Local\\1Password\\app\\8\\op-ssh-sign.exe
        gpgsign = true
        signingkey = ssh-ed25519
        name = username
        email = [email protected]
        editor = \"C:\\Users\\<user>\\AppData\\Local\\Programs\\Microsoft VS Code\\bin\\code\" --wait
        sshCommand= C:/Windows/System32/OpenSSH/ssh.exe
    $ socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork &
    [1] 3305
    2022/09/11 14:43:23 socat[3304] E "/home/<user>/.ssh/agent.sock" exists
  • jody.h_1Pjody.h_1P

    Team Member

    Hey @startcook1e it's possible there are other things going on, but for the error you're seeing (unsupported value for gpg.format: ssh) a good place to start would be to upgrade your Git version to 2.34.0 or later as this was when SSH commit signing was introduced.

  • aislandeneraislandener
    Community Member

    Hey @startcook1e i was able to sign the commit just by changing the pgp ssh program to windows using its mount point

    [user] email = [email protected] name = My Name signingkey = public key [gpg] format = ssh [gpg "ssh"] program = /mnt/c/Users/MyUser/AppData/Local/1Password/app/8/op-ssh-sign.exe [commit] gpgsign = true

    I hope you can do it

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file