[Windows] WSL integration possible using some extra tools

teh_c

Hello!

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

Thanks!

---

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

Lucent

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

MaxRaab

Would be great improvement.

ag_Christian

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.

Lucent

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

henriksoederlund

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

dmbuil

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.

henriksoederlund

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.

Lucent

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.

klinteastwood

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

ag_Christian

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!

ere

@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_Christian

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!

jirou

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

startcook1e

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 git@github.com:
git@github.com: 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 git@github.com

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

[gpg]
    format = ssh
[gpg "ssh"]
    program = C:\\Users\\<user>\\AppData\\Local\\1Password\\app\\8\\op-ssh-sign.exe
[commit]
    gpgsign = true
[user]
    signingkey = ssh-ed25519
    name = username
    email = email@gmx.de
[core]
    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_1P

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.

aislandener

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

[user] email = my-email@provider.com 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

thisdevdane

I tried @aislandener config and now get this error instead, not sure what file it cannot find

❯ git commit
error: Error: AppError { error: Os { code: 2, kind: NotFound, message: "The system cannot find the file specified." }, location: Location { file: "ssh\\op-ssh-sign\\src\\main.rs", line: 30, col: 13 } }

fatal: failed to write commit object

tghosth

Hi @ag_Christian, @jody.h_1P, is this solution using npiperelay and socat considered acceptable from a security perspective?

@teh_c, is this solution still working for you?

ag_Christian

Hey everyone,

To start, I have no update into "official" support for the integration, sorry.

Regarding the security of it, @tghosth, I don't believe it would be too much less secure then if we built it into 1Password for Windows ourselves. The only thing that comes to mind is that another process could utilize the trust 1Password applies to the proxy process to allow that other, unintended, process to use the SSH key without approval. Whether or not this is a true security problem is heavily dependent on your own threat model.

Additionally in the feature's experience, you may lose is contextual information or longer-lasting approvals by proxying the messages (which only have "public" data in them) through some relay process on your system.

mks0815

Still waiting on the Rust library issue mentioned above being fixed? Given the (lack of) progress in the referenced issue looks like we need to wait some more time.... In my company it would be much easier to use the solution built into an already "cleared for use" product than trying to get some tool (npiperelay) from github approved for use.