Open andreimaxim opened 1 month ago
How does WSL2 factor into this? It looks like you are running cmd/pwsh and the native ssh binary?
With mux_enable_ssh_agent = false
, what is your SSH_AUTH_SOCK
environment set to in your cmd/pwsh session where you run ssh
?
I suspect the problem here is really that that version of ssh doesn't support unix domain sockets:
I think the approach I'd like to take for this is to maybe try to intelligently select a default for mux_enable_ssh_agent
using a simple/cheap/effective probe of some kind that can detect when an existing agent is not reachable via unix domain.
I do want to note that simply defaulting it to false on Windows isn't something I really want to do, as wezterm ssh
and other ssh implementations do support unix domain sockets.
@wez sorry, I initially wrote "WSL2" because that's where I noticed it happening, but then I was able to reproduce it in Windows directly (I figured it's easier to test it like that). I've updated the title and removed the reference to WSL.
With mux_enable_ssh_agent = false, what is your SSH_AUTH_SOCK environment set to in your cmd/pwsh session where you run ssh?
It's not set.
I think it's expected for Windows to not set the SSH_AUTH_SOCK
environment variable at all (see PowerShell/Win32-OpenSSH#1136), as echo $env:SSH_AUTH_SOCK
in Windows Terminal + PowerShell does not return anything as well.
I think the approach I'd like to take for this is to maybe try to intelligently select a default for mux_enable_ssh_agent using a simple/cheap/effective probe of some kind that can detect when an existing agent is not reachable via unix domain.
Would it make sense to enable the SSH agent only if the "SSH_AUTH_SOCK" environment variable is set?
Would it make sense to enable the SSH agent only if the "SSH_AUTH_SOCK" environment variable is set?
It's unfortunately not that easy; it is often unset on most systems, when the desktop environment first loads.
I think it's expected for Windows to not set the
SSH_AUTH_SOCK
environment variable at all (see PowerShell/Win32-OpenSSH#1136), asecho $env:SSH_AUTH_SOCK
in Windows Terminal + PowerShell does not return anything as well.
When you first launch windows, is the agent started at login/boot, or does it spawn when ssh.exe
is launched?
If the agent is started before wezterm, then it may be possible to try to probe the \.\pipe\openssh-ssh-agent
path to decide if that agent is in use. Otherwise, I don't think there is a great option for this.
Windows comes with a SSH Authentication Agent service that will create \.\pipe\openssh-ssh-agent
at launch, but it is disabled by default. However, if you use 1Password and enable their SSH agent (and most likely any other software that might act as an SSH Agent), it will also create \.\pipe\openssh-ssh-agent
when 1Password starts.
That being said, I'm starting to think that the cleanest solution in this case is to add a warning somewhere (changelog? some FAQ?) about the potential behavior change on Windows due to this new feature.
Thank you very much for your work on WezTerm!
I just bumped into the same error with nightly wezterm build on Windows 10 (this is Server but I think the situation is identical to other consumer editions). With wezterm setting up $SSH_AUTH_SOCK
for me unnecessarily, and additionally the env variable is set to a non-existing file, causing auth to fail. Unsetting the env variable temporarily fixes auth for me. Besides, the problem is not limited to powershell (core); good ol' cmd.exe
also faces the same error.
Probing for existing named pipe without touching $SSH_AUTH_SOCK
is a solution for Microsoft port of OpenSSH. This native port enjoys increasing usage and is the default for Windows 10+. However the diversity of other ssh clients can mean more headache.
ssh
from Git for Windows is one such example, as well as all(?) MingW / MSYS derivated ssh
builds. Those do use $SSH_AUTH_SOCK
-- but they talk via Cygwin-compatible socket file. The env variable is generally managed by Windows users themselves.putty
which uses its own pageant
for nowBTW I should mention my setup too to show the diversity of possibilities in Windows. Maybe a bit similar to @wez usage of 1Password's agent, but with different software.
Agent: a KeePass plugin (KeeAgent), which opens necessary named pipe and Cygwin socket by itself Keys and passwords: stored within KeePass SSH binary:
pwsh
and cmd
: Microsoft port, but with its own agent disabled. $SSH_AUTH_SOCK
not set.MSYS2 bash
: Bundled ssh
, $SSH_AUTH_SOCK
set to socket file exported via KeeAgentWSL bash
: Bundled ssh
, with $SSH_AUTH_SOCK
set by helper script that communicates with named pipe in Windows host
What Operating System(s) are you seeing this problem on?
Windows
Which Wayland compositor or X11 Window manager(s) are you using?
N/A
WezTerm version
Nightly
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
When running the Nightly version on Windows 11 and using
ssh.exe
to connect to a remote host using a private key, the connection fails with aPermission denied (publickey)
.The verbose output:
I suspect that the following line shows the actual issue, as it does not appear in the logs of the current release, which does not exhibit this issue:
After some debugging, I believe that the issue was introduced in 4af418fddd0ed2d9a8861007112006fc657ecbac since setting
mux_enable_ssh_agent
tofalse
fixes the issue.To Reproduce
Connect to Github using the Windows SSH client using the Nightly WezTerm build:
Configuration
no config
Expected Behavior
The following output is expected:
Logs
No response
Anything else?
No response