Skip to content

Instantly share code, notes, and snippets.

@strarsis
Last active Nov 10, 2021
Embed
What would you like to do?
KeeAgent (for KeePass) on Bash on Windows / WSL

Update (Obctober 2020)

Thanks to the instructions for WSL 2 of the wsl-ssh-agent project, KeeAgent works great in WSL 2 now: https://github.com/rupor-github/wsl-ssh-agent#wsl-2-compatibility The approach uses minimal and well maintained tools.

Installation/setup

  1. Install the KeeAgent plugin for KeePass (2.x).
  2. The OpenSSH Authentication Agent Windows service must be stopped. For being sure that it stays stopped, even after rebooting, disable the service (when it is stopped).
  3. Open the KeeAgent options via KeePass Menu -> Tools -> Options -> KeeAgent Tab. Enable the option Enable agent for Windows OpenSSH (experimental) A possible error message Windows OpenSSH agent is already running. KeeAgent cannot listen for Windows OpenSSH requests. can be ignored, everything will still work fine. No socket files need to be created, the options can be left disabled.
  4. Necessary step (thanks @jacobblock): socat must also be installed:
sudo apt install socat
  1. Place the npiperelay.exe under /usr/local/bin/npiperelay.exe inside your WSL 2 installation. It must be on the devfs filesystem, see https://github.com/rupor-github/wsl-ssh-agent#wsl-2-compatibility. Download instructions (thanks @musm; thanks @dmwyatt):
wget https://github.com/rupor-github/wsl-ssh-agent/releases/download/v1.5.2/wsl-ssh-agent.zip -P /tmp
sudo 7z e -y /tmp/wsl-ssh-agent.zip -o/usr/local/bin/
sudo chmod +x /usr/local/bin/npiperelay.exe
rm /tmp/wsl-ssh-agent.zip
  1. Create a new script file ~/bin/wsl-ssh-agent-forwarder (thanks @r2evans) with the following contents:
#!/bin/bash
# Usage: wsl-ssh-agent-forward [ -k | -r ]
# Options:
#    -k    Kill the current process (if exists) and do not restart it.
#    -r    Kill the current process (if exists) and restart it.
# Default operation is to start a process only if it does not exist.

export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock

sshpid=$(ss -ap | grep "$SSH_AUTH_SOCK")
if [ "$1" = "-k" ] || [ "$1" = "-r" ]; then
    sshpid=${sshpid//*pid=/}
    sshpid=${sshpid%%,*}
    if [ -n "${sshpid}" ]; then
        kill "${sshpid}"
    else
        echo "'socat' not found or PID not found"
    fi
    if [ "$1" = "-k" ]; then
        exit
    fi
    unset sshpid
fi

if [ -z "${sshpid}" ]; then
    rm -f $SSH_AUTH_SOCK
    ( setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"/usr/local/bin/npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork & ) >/dev/null 2>&1
fi
  1. Make the script executable: chmod +x ~/bin/wsl-ssh-agent-forwarder
  2. Add the following line to your .bashrc (~/.bashrc) to execute the script above:
# KeeAgent
. ~/bin/wsl-ssh-agent-forwarder

It is important that the script is sourced (. is shorthand for source), not just executed inside .basrc, as otherwise the exported environment variables would be used for the child process. The VSCode terminal is a case for this.

  1. Important: Ensure the socket file exists (even just as an empty placeholder file)!
mkdir -p $HOME/.ssh
touch $HOME/.ssh/agent.sock
  1. (Tip) Reload .bashrc config in current bash session:
$ source ~/.bashrc
  1. You can check the key agent functionality by either connecting via SSH or listing the keys with ssh-add -l (thanks @jacobblock). KeePass should automatically show the authentication prompt and/or notify that SSH keys have been accessed. Note: The KeePass program must be running when KeeAgent should be used. Turning on KeePass autostart could be a good idea.

Note: Comments below may relate to the outdated Howto for WSL 1 and msysgit2unix-socket.py!

@gpion

This comment has been minimized.

Copy link

@gpion gpion commented Feb 21, 2018

Not working here. I'm getting error "socket.error: [Errno 98] Address already in use" at line 231 ("MSysGit2UnixSocketServer(pair[0], pair[1]")

"pair" array contents are OK though.

Traceback:

  File "/home/gilles/bin/msysgit2unix-socket.py", line 231, in <module>
    MSysGit2UnixSocketServer(pair[0], pair[1])
  File "/home/gilles/bin/msysgit2unix-socket.py", line 136, in __init__
    self.bind(unix_socket_path)
  File "/usr/lib/python2.7/asyncore.py", line 342, in bind
    return self.socket.bind(addr)
  File "/usr/lib/python2.7/socket.py", line 228, in meth
    return getattr(self._sock,name)(*args)
socket.error: [Errno 98] Address already in use
@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Mar 24, 2018

@gpion: Is /tmp/.ssh-auth-sock writable/removable by the user? Also manually remove it and try again.

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Mar 24, 2018

For a particular SSH server I get this error on client side:

sign_and_send_pubkey: signing failed: agent refused operation
@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Jan 26, 2020

Sometimes it helps to just remove the SSH auth socket file: rm /tmp/.ssh-auth-sock

@jetzerb

This comment has been minimized.

Copy link

@jetzerb jetzerb commented Feb 20, 2020

Do you know if there's a way to make this work from inside a Linux Docker container?

I have KeeAgent running on my Windows 10 laptop, and I'd like it to serve keys to my ssh client that's running inside of a Linux-based docker container.

I have created both the cygwin and msysgit socket files, and can see them from Windows File Explorer. That folder is visible from the docker container, but ls doesn't seem to know about those socket files. Interestingly enough, they are visible from powershell and WSL, but not from a dos prompt. I went ahead and tried the msysgit2unix-socket.py, but when ssh -v to a server, I get

. . .
debug1: pubkey_prepare: ssh_fetch_identitylist: communication with agent failed
. . .

Our internal IT staff manage our KeePass installations and databases: when I start KeePass, it authenticates me via my Windows credentials and automatically downloads and opens my personal KP DB from some network share. Thus, running KeePass from inside the docker container isn't really an option.

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Feb 20, 2020

@jetzerb: You could try to mount that socket file into the docker container to make it available. It should actually work.

@jetzerb

This comment has been minimized.

Copy link

@jetzerb jetzerb commented Feb 21, 2020

Here's my (unsuccessful) attempt after bind mounting the socket file individually.
Error message is pubkey_prepare: ssh_fetch_identitylist: communication with agent failed
I can't help but think that in the whole NTFS -> DockerDesktopVM filesystem -> container filesystem process, some of the sockety magic of the file may not be mapped correctly/completely...

Any other ideas? I appreciate the help.

PS C:\Users\jetzerb> docker run -it --mount type=bind,source=/c/Users/jetzerb/msyssock,target=/tmp/socksrc ubuntu:19.04

root@1961d92e32e4:/# ls -l /tmp
total 0
-rwxr-xr-x 1 root root 51 Feb 20  2020 socksrc
root@1961d92e32e4:/# cat /tmp/socksrc
!<socket >58537 38654779-47D6D080-7352A693-F1798748root@1961d92e32e4:/#

root@1961d92e32e4:/# apt-get update && apt-get install --no-install-recommends ssh ca-certificates python wget
. . . snip . . .
. . . download & chmod msysgit2unix-socket.py per instructions above . . .

root@1961d92e32e4:/# export SSH_AUTH_SOCK=/tmp/.ssh-auth-sock
root@1961d92e32e4:/# ~/bin/msysgit2unix-socket.py /tmp/socksrc:$SSH_AUTH_SOCK
root@1961d92e32e4:/# ls -la /tmp
total 12
drwxrwxrwt 1 root root 4096 Feb 19 03:46 .
drwxr-xr-x 1 root root 4096 Feb 19 03:40 ..
srwxr-xr-x 1 root root    0 Feb 19 03:46 .ssh-auth-sock
-rw-rw-rw- 1 root root    5 Feb 19 03:46 msysgit2unix-socket.pid
-rwxr-xr-x 1 root root   51 Feb 20  2020 socksrc

root@1961d92e32e4:/# ssh -v myUserName@myRemoteHost
OpenSSH_7.9p1 Ubuntu-10, OpenSSL 1.1.1b  26 Feb 2019
. . . snip . . .
debug1: pubkey_prepare: ssh_fetch_identitylist: communication with agent failed
debug1: Will attempt key: /root/.ssh/id_rsa
debug1: Will attempt key: /root/.ssh/id_dsa
debug1: Will attempt key: /root/.ssh/id_ecdsa
debug1: Will attempt key: /root/.ssh/id_ed25519
debug1: Will attempt key: /root/.ssh/id_xmss
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Trying private key: /root/.ssh/id_xmss
debug1: No more authentication methods to try.
myUserName@myRemoteHost: Permission denied (publickey).

Here's the relevant section from docker inspect:

        "Mounts": [
            {
                "Type": "bind",
                "Source": "/host_mnt/c/Users/jetzerb/msyssock",
                "Destination": "/tmp/socksrc",
                "Mode": "",
                "RW": true,
                "Propagation": "rprivate"
            }
        ],
@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Feb 21, 2020

@jetzerb:

  1. Can you use the socket in your WSL setup?
  2. Go into the container and use something like stat on the socket file, can you access it

Btw.: There should be an update for Windows/WSL soon that offers native socket support which
would also eliminate the need for such workarounds as described in this HOWTO.

@jetzerb

This comment has been minimized.

Copy link

@jetzerb jetzerb commented Feb 21, 2020

@strarsis

  1. Yes, I can use the socket generated by the python script in WSL 1 (my corporate IT dept has not yet blessed the update which would allow me to use WSL 2, so can't test that).
  2. Yes, I can stat the file from within the container:
root@92cc7ee3a60a:~/bin# cd /tmp
root@92cc7ee3a60a:/tmp# ls -la
total 12
drwxrwxrwt 1 root root 4096 Feb 19 05:21 .
drwxr-xr-x 1 root root 4096 Feb 19 05:18 ..
srwxr-xr-x 1 root root    0 Feb 19 05:21 .ssh-auth-sock
-rw-rw-rw- 1 root root    5 Feb 19 05:21 msysgit2unix-socket.pid
-rwxr-xr-x 1 root root   51 Feb 20  2020 socksrc
root@92cc7ee3a60a:/tmp# stat .ssh-auth-sock
  File: .ssh-auth-sock
  Size: 0               Blocks: 0          IO Block: 4096   socket
Device: 88h/136d        Inode: 19500       Links: 1
Access: (0755/srwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-02-19 05:21:27.257290356 +0000
Modify: 2020-02-19 05:21:27.257290356 +0000
Change: 2020-02-19 05:21:27.257290356 +0000
 Birth: -
root@92cc7ee3a60a:/tmp# stat socksrc
  File: socksrc
  Size: 51              Blocks: 0          IO Block: 4096   regular file
Device: 68h/104d        Inode: 58828270132720645  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-02-20 20:51:13.541804700 +0000
Modify: 2020-02-20 20:51:13.541804700 +0000
Change: 2020-02-20 13:53:41.208179000 +0000
 Birth: -

I thought perhaps the "regular file" designation might be problematic, but that's the same way the file is seen by WSL:

root@JETZERB10:~/bin# stat /mnt/c/Users/jetzerb/msyssock
  File: '/mnt/c/Users/jetzerb/msyssock'
  Size: 51              Blocks: 0          IO Block: 4096   regular file
Device: 13h/19d Inode: 58828270132720645  Links: 1
Access: (0777/-rwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-02-20 14:51:13.541804700 -0600
Modify: 2020-02-20 14:51:13.541804700 -0600
Change: 2020-02-20 14:51:13.541804700 -0600
 Birth: -
@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Feb 21, 2020

@jetzerb: Looks good so far. Mounting sockets into docker container is routinely done, e.g. with Traefik and the docker daemon socket, see
https://medium.com/better-programming/about-var-run-docker-sock-3bfd276e12fd and https://docs.traefik.io/providers/docker/#docker-api-access. I wonder why the SSH agent is unable to use the socket. The SSH agent runs inside the docker container... maybe the socket file permission only allows its owner to read it and the SSH agent doesn't run under the current socket file owner?

@jetzerb

This comment has been minimized.

Copy link

@jetzerb jetzerb commented Feb 21, 2020

@strarsis yes, but that's a Linux socket bind-mounted into Linux containers. In this situation, we're talking about a Windows/NTFS socket file residing on a filesystem that is mounted in the Docker for Windows Linux VM and from there bind-mounted into the Linux containers. Here's how the KeeAgent socket file appears in various environments. First, a screenshot showing what Windows File Explorer thinks of it (system file), along with Git Bash (socket) and WSL (regular file):
image

And now an illustration of how the docker socket (which originates in the Linux VM created by Docker Desktop) comes through as a socket file in the container, whereas the socket created by KeeAgent on Windows/NTFS is presented as a regular file:

docker run -it --mount type=bind,source=/c/Users/jetzerb/msyssock,target=/tmp/socksrc --mount type=bind,source=/var/run/docker.sock,target=/tmp/sockdock ubuntu:19.04
root@add530428f34:/# cd /tmp
root@add530428f34:/tmp# ls -laF
total 8
drwxrwxrwt 1 root root 4096 Feb 19 05:46 ./
drwxr-xr-x 1 root root 4096 Feb 19 05:46 ../
srw-rw---- 1 root root    0 Feb 11 19:26 sockdock=
-rwxr-xr-x 1 root root   51 Feb 20  2020 socksrc*
root@add530428f34:/tmp# stat sockdock
  File: sockdock
  Size: 0               Blocks: 0          IO Block: 4096   socket
Device: 4ah/74d Inode: 17130       Links: 1
Access: (0660/srw-rw----)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-02-11 19:26:44.008350681 +0000
Modify: 2020-02-11 19:26:43.306350681 +0000
Change: 2020-02-11 19:26:43.306350681 +0000
 Birth: -
root@add530428f34:/tmp# stat socksrc
  File: socksrc
  Size: 51              Blocks: 0          IO Block: 4096   regular file
Device: 68h/104d        Inode: 58828270132720645  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-02-20 20:51:13.541804700 +0000
Modify: 2020-02-20 20:51:13.541804700 +0000
Change: 2020-02-20 13:53:41.208179000 +0000
 Birth: -
@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Feb 21, 2020

@jetzerb: This makes sense. You would have to either mount the socket converted by msysgit2unix-socket.py or the original windows socket and convert it inside the container using msysgit2unix-socket.py.

@musm

This comment has been minimized.

Copy link

@musm musm commented Jun 18, 2020

What about WSL2? I'd love to get KeeAgent to work here.

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Jun 18, 2020

@musm: Haven't installed/tried WSL 2 yet (using stable Windows channel). I will definitely try to set it up there, too, when I start using it.

@musm

This comment has been minimized.

Copy link

@musm musm commented Jun 18, 2020

Are you on the May update? If you are, this is on the stable channel, WSL 2 is available and there's an option to upgrade to WSL 2 existing containers

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Jun 18, 2020

While you were talking about it, I just noticed there is the "2004" ("May") update, I will try to install it.

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Jun 19, 2020

@musm:

Update (June 2020)

Thanks to the instructions for WSL 2 of the wsl-ssh-agent project, KeeAgent works great in WSL 2 now:
https://github.com/rupor-github/wsl-ssh-agent#wsl-2-compatibility
The approach uses minimal and well maintained tools.

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Sep 1, 2020

@gpion, @jetzerb, @musm, @amasolag, @dten, @mlueckert, @vbrozik, @RaveNoX, @jwhb, @fgoebel:
I updated this Howto gist for WSL 2 and the newly available WSL SSH Agent.
It should work well now with WSL 2 and latest KeeAgent.

@jacobblock

This comment has been minimized.

Copy link

@jacobblock jacobblock commented Sep 3, 2020

This guide is excellent, thank you! Along with npiperelay.exe being on path you need socat installed. The details are on https://github.com/jstarks/npiperelay but I forgot after rebuilding my environment.

sudo apt install socat then source your bashrc again to start the pipe again npiperelay: source ~/.bashrc. Then you should see your keys with ssh-add -l.

Cheers!

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Sep 3, 2020

@jacobblock: Thanks, I added your extra step to the guide and also mention the ssh-add -l command for testing the key agent functionality.

@r2evans

This comment has been minimized.

Copy link

@r2evans r2evans commented Sep 26, 2020

@strarsis, I find I have to periodically restart the socat ... process, not sure why. For that, I updated your script a touch, including it in case you or anybody else are interested or can suggest improvements.

Edit (2021-02-11): this is an external script I've named ~/bin/wsl-ssh-agent-forwarder. If you want something in your ~/.bashrc, then I suggest keeping this below as its own script and adding wsl-ssh-agent-forwarder to ~/.bashrc.

#!/bin/bash
# Usage: wsl-ssh-agent-forward [ -k | -r ]
# Options:
#    -k    Kill the current process (if exists) and do not restart it.
#    -r    Kill the current process (if exists) and restart it.
# Default operation is to start a process only if it does not exist.

export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock

sshpid=$(ss -ap | grep "$SSH_AUTH_SOCK")
if [ "$1" = "-k" ] || [ "$1" = "-r" ]; then
    sshpid=${sshpid//*pid=/}
    sshpid=${sshpid%%,*}
    if [ -n "${sshpid}" ]; then
        kill "${sshpid}"
    else
        echo "'socat' not found"
    fi
    if [ "$1" = "-k" ]; then
        exit
    fi
    unset sshpid
fi

if [ -z "${sshpid}" ]; then
    rm -f $SSH_AUTH_SOCK
    ( setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"/mnt/c/Users/r2/bin/npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork & ) >/dev/null 2>&1
fi

The ss -ap returns something along the lines of

u_str LISTEN 0      5                                  /home/r2/.ssh/agent.sock 88692                   * 0           users:(("socat",pid=959,fd=5))

where pid=959 is the clue on how to kill the current process.

@musm

This comment has been minimized.

Copy link

@musm musm commented Sep 29, 2020

One line install npiperelay.exe

wget -q https://github.com/rupor-github/wsl-ssh-agent/releases/download/v1.4.2/wsl-ssh-agent.7z -P /tmp
7z e -y /tmp/wsl-ssh-agent.7z -o$HOME/bin/ npiperelay.exe > /dev/null
rm -rf /tmp/wsl-ssh-agent.7z

append to bashrc

    export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock
    ss -a | grep -q $SSH_AUTH_SOCK
    if [ $? -ne 0   ]; then
        rm -f $SSH_AUTH_SOCK
        ( setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork & ) >/dev/null 2>&1
    fi
@r2evans

This comment has been minimized.

Copy link

@r2evans r2evans commented Sep 29, 2020

That looks like more than one line ... ;-)

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Oct 3, 2020

I added these lines to the README so one can use them for quickly installing npiperelay.exe.

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Oct 4, 2020

@musm, @r2evans: I added your contributions to the README. It is amazing how we all help to create a well-working README!

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Nov 12, 2020

I noticed that sometimes the ss command for listing sockets (ss -ap | grep "$SSH_AUTH_SOCK") also lists the socket used for KeeAgent connection (~/.ssh/agent.sock) although no socket file exists and can be used by the WSL 2 system.
Hence I think an additional condition for the non-existence of that socket file should be added:

if [ "$1" = "-k" ] || [ "$1" = "-r" ] || [ ! -f "$SSH_AUTH_SOCK" ]; then
@vbrozik

This comment has been minimized.

Copy link

@vbrozik vbrozik commented Feb 9, 2021

@r2evans I cannot figure out where do the CLI arguments -k and -r in your script come from. Could you please give a clue?

@r2evans

This comment has been minimized.

Copy link

@r2evans r2evans commented Feb 9, 2021

-k kills the current agent (if found) and exits. -r kills the current agent (if found) and tries to start another.

Often, due to windows' hibernation or network glitches or something else, the agent stops working (though has not exit). When that happens, I type wsl-ssh-agent-forwarder -r and very quickly I'm back up. There are times when I need the agent to stop completely and exit, ergo -k.

I'm looking at "$1" when comparing for -r/-k, and $1 is the first positional command-line argument of the script.

@vbrozik

This comment has been minimized.

Copy link

@vbrozik vbrozik commented Feb 11, 2021

@r2evans OK, I know how positional arguments in Bourne-based shells work but in this case the code is part of ~/.bashrc. AFAIK in ~/.bashrc there are normally no positional arguments. You can pass them using -s like this: bash -s -- -k but I think it is not our case.

Thank you for the example. Now I think I understand your code. It is intended to be used in a separate shell script - not as part of ~/.bashrc and you are using the arguments only during manual invocation of the script.

As it is described in this readme (put the code into ~/.bashrc) your added code is a dead code which never gets executed.

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Feb 11, 2021

Should something be improved in the README? The bash script?

@r2evans

This comment has been minimized.

Copy link

@r2evans r2evans commented Feb 11, 2021

I never put that much context-specific code in my ~/.bashrc script, it's too risk and does not enable me to reset when needed. I should have been more clear on that, I've edited that comment to make it more clear.

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Feb 11, 2021

@r2evans: How can the bash code be improved? I am really interested in improving it (as I am using it myself).

@r2evans

This comment has been minimized.

Copy link

@r2evans r2evans commented Feb 11, 2021

@starsis, I think the bash script is fine. I do not agree with the premise of putting all of that code directly into the ~/.bashrc file, for several reasons:

  1. Keep .bashrc simple and clean;
  2. Keep the functionality separate so that it can be called separately (as in my use-case with -k or -r);
  3. Version control, this script is completely independent of everything else in .bashrc.

So the contents of the script are unchanged other than the comments I added in my comment.

@vbrozik

This comment has been minimized.

Copy link

@vbrozik vbrozik commented Feb 11, 2021

@strarsis r2evans edited the original post already to explain the usage. The placement in ~/bin/ is OK. Ubuntu adds this directory to $PATH for login shells.

Possibly you can make the script available system-wide in /usr/local/bin/ but then the script should be extended to work for all the users. This would probably not be worth of the effort as additional users are not normally being used in WSL. For example VS Code does not work with non-default users.

@r2evans

This comment has been minimized.

Copy link

@r2evans r2evans commented Feb 11, 2021

If you have multiple Windows users, /usr/local/bin is not a bad place for it, with the assumption that if they choose to use it, they'll know what else they may need. I prefer that generally to the use of ~/bin/, but use the latter because nobody touches my laptop :-)

Having it in the PATH is completely optional. If it is, then it is convenient for the few times I have to reset it, but that is solely the difference between typing ~/bin/wsl-<tab> -r and wsl-<tab> -r. I do this once or max twice a day, not a problem for me.

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Feb 11, 2021

@r2evans, @vbrozik: I adjusted the README above.
I had some issues with permissions/ownership on WSL 2 with the ~/bin/ path,
what do you think about using /usr/local/bin? Would you be both happy with that? 😸

@r2evans

This comment has been minimized.

Copy link

@r2evans r2evans commented Feb 11, 2021

Don't know what wsl problems could be, but I'm good. (I see you copied my comment verbatim, including the extra space I didn't see until now ... my typography-OCD is a curse :-)

Thanks

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Feb 11, 2021

@r2evans: What extra space? Should it be removed?

@r2evans

This comment has been minimized.

Copy link

@r2evans r2evans commented Feb 11, 2021

# Options:
#    -k    Kill the current process (if exists) and do not restart it.
#    -r     Kill the current process (if exists) and restart it.
           ^ this extra space, completely cosmetic

I have since edited my comment with the original code. Really, this is just cosmetic, too much noise for my OCD, I was part-joking, part-poking-myself, and certainly not-at-all criticizing you.

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Feb 11, 2021

@r2evans: Thanks!

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Feb 12, 2021

It is necessary to source that bash script in .bashrc, otherwise issues can arise, as with the VSCode terminals.

@vbrozik

This comment has been minimized.

Copy link

@vbrozik vbrozik commented Feb 12, 2021

@strarsis you are right otherwise the variable SSH_AUTH_SOCK would not be set in the shell. The code cannot work completely as a script being called the normal way.

@r2evans

This comment has been minimized.

Copy link

@r2evans r2evans commented Feb 12, 2021

good point, so . ~/bin/wsl-ssh-agent-forwarder the first time is necessary. After that, the external script will work fine, since SSH_AUTH_SOCK is unchanged from when it was sourced originally.

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Feb 14, 2021

@r2evans: I just noticed that in your example the npiperelay.exe is located on a normal Windows file sytem, not a devfs file system (WSL 2).
However, the npiprelay.exe documentation stresses that it works only when it is launched from within WSL 2, otherwise it would not work.
Does it still work for you?

@r2evans

This comment has been minimized.

Copy link

@r2evans r2evans commented Feb 14, 2021

It is on the normal windows filesystem, which I access via /mnt/c/. Yes it works. So according to the process, it is on a local filesystem (which happens to be mounted on /mnt/c). *shrug*

@dmwyatt

This comment has been minimized.

Copy link

@dmwyatt dmwyatt commented Apr 8, 2021

Note that as of right now the latest version of wsl-ssh-agent.7z is 1.5.0. Make the appropriate changes to the wget command...

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Apr 9, 2021

@dmwyatt: I updated the version.

Edit: wsl-ssh-agent v1.5.1 was accidentally named wsl-gpg-agent (see rupor-github/wsl-ssh-agent#23).
This was fixed with v1.5.2 which is also used in this guide now. The release file format changed from tar to zip by the way.

@eddieparker

This comment has been minimized.

Copy link

@eddieparker eddieparker commented Sep 10, 2021

Thank you for making this!

I turned this into an ansible playbook so it's easy for me to use on my various boxes. Thought I'd share my gist in case it's useful to others: https://gist.github.com/eddieparker/27ed73e657338f2c0c6ef53464343748

@strarsis

This comment has been minimized.

Copy link
Owner Author

@strarsis strarsis commented Sep 10, 2021

@eddieparker: That's very nice, thank you.

@caltuntas

This comment has been minimized.

Copy link

@caltuntas caltuntas commented Oct 8, 2021

Worked like a charm, I'm able to serve my SSH keys stored on KeePass to both Ubuntu Wsl2 and Windows OpenSSH at the same time. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment