Usage of wezterm ssh with ssh-agent on Windows 11

[antoineco]

I have the "OpenSSH Authentication Agent" (ssh-agent) service running on my machine, and I successfully added my SSH key using ssh-add:

(PowerShell 7.3.4)

> ssh-add .\.ssh\auth
Enter passphrase for .\.ssh\auth:
Identity added: .\.ssh\auth (acotten)

> ssh-add -L
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBrWkMRdF5phpLftdUHIgcSnSIKunqBecVN1jgSkuz8H acotten

However, wezterm ssh is not picking the key from the agent, and prompts me to enter the passphrase again:

> wezterm ssh myhost
(new window)
Using libssh-rs to connect to [email protected]:22
SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u1
Passphrase (C:\Users\acott\.ssh\auth):

This does not happen if I connect to the same host with the ssh command.

Could anyone share some pointers about how to solve this?

---

Update

After some research, I found that the OpenSSH agent's (named) pipe was located at \\.\pipe\openssh-ssh-agent.

I tried adding the following directive to my configuration:

Host bench
  User acotten
  Hostname XXX.XXX.XXX.XXX
  IdentityFile C:\Users\acott\.ssh\auth
  IdentitiesOnly true
  IdentityAgent \\.\pipe\openssh-ssh-agent

Unfortunately this doesn't seem supported by libssh-rs:

INFO   libssh::ssh_socket_unix                    > Error from connect(\\.\pipe\openssh-ssh-agent): No such file or directory
INFO   libssh::ssh_userauth_publickey_auto        > Trying to authenticate with C:\Users\acott\.ssh\auth

[wez]

Is it possible to configure your ssh agent to use a unix domain socket instead of a named pipe?

[antoineco]

I did not even know this was a thing on Windows, until I read https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/ 👀

The answer is no, but your comment prompted me to search Microsoft's related OSS project, and there is a PR open to support that: PowerShell/openssh-portable#674

[wez]

Ah, good. I was the person that added IdentityAgent support to libssh, and enabled unix domain support there for Windows (at my former place of work, we had a custom ssh agent that did some stuff with the TPM to manage secrets, and that was exposed via unix domain).

I commented on another question/issue from you about this or a similar thing: you'll need libssh to support named pipes in order for wezterm to support them.

Making unix software support named pipes is generally difficult because the semantics are similar in some ways but very different in some very painful other ways; named pipes can block forever in a number of situations, which is usually at odds with the non-blocking approach used in the vast majority of unix applications.

I personally won't be working to enable named pipes in libssh because I have no need for it.

I think the best longer term bet is MS shipping unix domain support.

In the shorter term, if I were in your situation I would consider:

• Is there an alternative ssh agent that I could use? eg: using WSL 1 you can use interop to have it place the socket on the host filesystem and share out from the agent inside a WSL container
• Could you do something netcat-or-socat-like with a program that listens on a unix socket and proxies the connections to the named pipe? That program probably wouldn't be all that difficult to write if there isn't already a thing that does it

[wez]

this comment might point you to the second option I suggested:

• tmux: ambiguous double width / single width characters rendered differently under tmux #3704 (comment)

[antoineco]

Those are good suggestions.

I agree that supporting named pipes isn't a requirement since libssh already supports Unix domain sockets, and the fact that Windows itself supports AF_UNIX changes everything.

npiperelay indeed looks simple enough. I will look into using it in conjunction with ncat, for the Unix socket end on Windows.

---

WSL2 side notes:

• I attempted to configure the client to connect directly to the SSH agent running inside my main WSL instance over the 9p share, but this isn't supported:

  Host bench
    IdentityAgent \\wsl.localhost\Ubuntu\tmp\ssh-XXXXXXviy435\agent.397
  

• Starting the SSH agent within WSL2 with a bind address on the host's 9p share is also not supported:

  $ ssh-agent -a /mnt/c/Users/acotten/.ssh/agent.sock
  unix_listener: cannot bind to path /mnt/c/Users/acotten/.ssh/agent.sock: Operation not supported

[naikrovek]

at my former place of work, we had a custom ssh agent that did some stuff with the TPM to manage secrets, and that was exposed via unix domain

😲

[Oddegamra]

Having struggled with this problem myself today, I will add for anyone happening across this page that setting ssh_backend = "Ssh2" in Wezterm's configuration will, in fact, connect to the OpenSSH Agent on Windows via named pipe if it is set up correctly in ~/.ssh/config. This also applies to Putty's Pageant, which now also uses named pipes.

[rgwood]

Great tip!

Confirmed that config.ssh_backend = "Ssh2" uses the OpenSSH Agent as expected. I did not need to make any changes to my ~/.ssh/config file.

[acuteaura]

"unable to exchange encryption keys" for me when using 1password, which you also can't configure to use a unix socket.

[gsommer]

It does not work for me. What do you mean with "if it is set up correctly in ~/.ssh/config"?

If I use ssh in a powershell window, I do not need to enter the password. but using "wezterm ssh" prompts for the password, though wezterm uses the configuration from .ssh\config, same as the ssh command (I did not put any configuration into wezterm.lua).

It also works from Windows Terminal.

I would really appreciate your help, as always having to enter the password is annoying.