wez / wezterm

A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust
https://wezfurlong.org/wezterm/
Other
17.28k stars 781 forks source link

KeeAgent on Windows ssh authentication socket of AF_UNIX type is blocked by wezterm #3345

Closed nerditation closed 1 year ago

nerditation commented 1 year ago

What Operating System(s) are you seeing this problem on?

Windows

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

wezterm 20230323-201243-c38d1609

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

KeeAgent (a plugin for KeePass) is an ssh agent program that support different agent protocols such as pagent (Win32 message), openssh (named pipe), wsl1 (AF_UNIX socket), and even cygwin emulated unix socket too.

when I use wezterm to make a ssh connection (either using wezterm connect or wezterm ssh command) authenticated through KeeAgent, the authentication socket won't accept new connectiosn until the wezterm-gui window process quits; even after I ended the ssh session (by detaching or closing all tabs of the session), as long the same gui window is still open . the agent socket is unavailable, I can't even re-connect to the same session that I just detached from the same window.

if I try to connect to multiple remote sessions from the same gui window, the second session would block on the auth socket, the screen got stuck at:

Connecting to 10.xx.xx.xx using SSH
Using libssh-rs to connect to username@10.xx.xx.xx
SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u1

but what's even worse is, the first session would also have problem when disconnecting, and the entire gui window would even freeze if I try to detach the first session.

ultimately, kill the ssh agent process would unblock all the frozen window and tabs, of course the authentication would fail.

To Reproduce

  1. install KeeAgent: instruction
  2. make sure KeeAgent is configured to enable []WSL1 compatible socket file: documentation (image slightly outdated)
  3. load a private key into KeeAgent, supports both putty format (.ppk) and openssh format (id_rsa etc); you don't need an KeePass database, you can load private key from files directly, open KeeAgent manager from the tools menu.
  4. make SSH_AUTH_SOCK environment variable pointing to the socket file created by KeeAgent
  5. make a ssh connection using wezterm: wezterm connect username@address
  6. make another ssh connection that authenticates using the same socket, for instance, you can either
    • use the ssh command under a wsl1 shell, or
    • use wezterm again, the same server will do

Configuration

no config is needed

Expected Behavior

with a wezterm managed ssh connection active, you can still auth new ssh connections using the agent.

Logs

nothing relevant in the log, but anyway here it is:

the first window which authenticated successfully:

Debug Overlay
wezterm version: 20230323-201243-c38d1609 x86_64-pc-windows-msvc
Window Environment: Windows
OpenGL version: AMD Radeon(TM) Graphics 4.5.0 Core Profile Context 22.20.16.03.220829
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit
14:24:15.508 WARN wezterm_ssh::pty > ssh: setenv TERM_PROGRAM=WezTerm failed: RequestDenied: Channel request env failed. Check the AcceptEnv setting on the ssh server side. Additional errors with setting env vars in this session will be logged at debug log level.
>

the second window which got stuck:

Debug Overlay
wezterm version: 20230323-201243-c38d1609 x86_64-pc-windows-msvc
Window Environment: Windows
OpenGL version: AMD Radeon(TM) Graphics 4.5.0 Core Profile Context 22.20.16.03.220829
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit
>

Anything else?

it could be a KeeAgent problem, but I suspect it is more likely from wezterm. but I lack the expertise to track down the true cause. after all, AF_UNIX is not really a "native" thing for Windows.

I noticed that, while the wsl1 auth socket was blocked, other protocols still work fine, (I tested openssh and putty, but I suppose the cygwin would also be ok). additionally, I can make as many ssh connections in a wsl1 shell, and they would not block each other, nor would they block wezterm, but as long wezterm made a connection, I can't make new ssh connections from wsl1.

wez commented 1 year ago

The underlying libssh library keeps the agent socket alive for the duration of its session. I don't think that is a bug, as the agent may be used to forward authentication to other hosts.

You can discuss this with the libssh folks in their issue tracker: https://gitlab.com/libssh/libssh-mirror

but it sounds like KeeAgent has a faulty implementation if it only allows a single client to be connected at a time.

nerditation commented 1 year ago

ah, this makes perfect sense, and I opened an issue on SshAgentLib which KeeAgent is based on.

I also took a look at openssh, it turns out that they only uses the agent socket during authentication. in funciton ssh_userauth2, agent socket is opened by calling pubkey_prepare, and then closed later by calling pubkey_cleanup

it seems openssh happened to not trigger KeeAgent's limitation. I'm not saying the difference between openssh and libssh means one of them is incorrect. I think both strategies are reasonable.

but I was so curious how openssh handles agent forwarding. well, they reconnect the agent when the an agent forwarding channel is established, in function client_request_agent. I guess the reason is, openssh supports forwarding an agent socket which is different from the one used to authenticate the user. I didn't know this was a thing before. man page: link

wez commented 1 year ago

I'm going to close this as it looks like it has been fixed in KeeAgent's main branch.

github-actions[bot] commented 1 year ago

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.