Basic shim to call WSL executable with same name as this BAT file

ssh.BAT

@echo off
::
:: Basic shim to call WSL executable with same name as this BAT file
::
:: Copyright (c) 2020 Dale Phurrough with MIT License:
:: Permission is hereby granted, free of charge, to any person obtaining a copy
:: of this software and associated documentation files (the "Software"), to deal
:: in the Software without restriction, including without limitation the rights
:: to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
:: copies of the Software, and to permit persons to whom the Software is
:: furnished to do so, subject to the following conditions:
:: The above copyright notice and this permission notice shall be included in all
:: copies or substantial portions of the Software.
:: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
:: IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
:: FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
:: AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
:: LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
:: OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
:: SOFTWARE.
::
:: Indiscriminate mutation of parameters. You can add/adjust.
:: * change backslash to forward slashes
:: * change case-insensitive c: to /mnt/c
::
:: Install
:: 1.  Windows 10 v1903 or newer with a working WSL installation.
:: 2.  Make a copy of this file and name it the same as your WSL executable plus the extension ".BAT".
::     The extension ".BAT" must be capital letters. For example:
::     a) to run ssh in WSL, name this file "ssh.BAT"
::     b) to run ctags in WSL, name this file "ctags.BAT"
:: 3.  Your WSL .profile and .bashrc must not add any output. Otherwise, their output would be mixed
::     with the WSL executable's output and corrupt the data stream.
:: 4.  Test your install by copying this BAT file to "true.BAT"
:: 5.  At a CMD prompt, type:  true.BAT
:: 6.  You should see no output and no errors
:: 7.  At the same CMD prompt, type:  true.BAT > true.out
:: 8.  You should see no output and no errors
:: 9.  At the same CMD prompt, type:  dir true.out
:: 10. You should see a file named "true.out" with a file size of 0 bytes.
::     If you have any size greater than 0 bytes, then you must edit your WSL .profile and .bashrc
::     so that they add no output to stdout/stderr.
::
:: Hints
:: 1   Be mindful of your PATH
::     a) the location you save this BAT file may be (or not) in your PATH
::     b) the order of your PATH is important. For example, Windows 10 often has installed a Win32 executable
::        named "ssh.EXE" and it is usually in your PATH. If you created "ssh.BAT", then the order in which
::        your PATH is searched will determine which ssh is run.
::     c) If you specify the full path to your ssh.BAT file, you can avoid PATH search issues
:: 2.  To use this file for ssh in VSCode, I recommend your edit VSCode settings.json to declare
::     the full path to this file. Capitalize the drive letter and use double-backslashes to separate
::     the directory names. E.g.:
::         "remote.SSH.path": "C:\\path\\to\\your\\folder\\ssh.BAT",
:: 3.  Some components of VSCode only look in PATH for tools like ssh. These components ignore
::     the settings "remote.SSH.path". You may be forced to edit your PATH, uninstall the Win32 ssh.EXE, etc.
::     so that this "ssh.BAT" is used by VSCode.
::
SETLOCAL EnableExtensions
SETLOCAL DisableDelayedExpansion
set v_params=%*
set v_params=%v_params:\=/%
set v_params=%v_params:c:=/mnt/c%
REM set v_params=%v_params:"=\"%
C:\Windows\system32\wsl.exe %~n0 %v_params%

Just tested the script on my machine and work without any problem. Thank you!

@diablodale awesome

Thanks, but this doesn't work with SSH keys that have passwords :(

@jordantrizz perhaps your usage doesn't support such. I"m sure you can find something that works for you now that 4 years have passed.

FYI, ssh passwords worked for me...part of the whole reason I used this along with GPG across the WIn/WSL boundary.

@jordantrizz perhaps your usage doesn't support such. I"m sure you can find something that works for you now that 4 years have passed.

You'd be surprised, I can't find an alternative to use my WSL environment .ssh/config :( Perhaps it's buried in the interwebs, and I just need to spend a night searching for an alternative.

I wasn't using ssh.bat as the file name, mistake #1

Also had to add these to Visual Studio Code user preferences.

    "remote.SSH.showLoginTerminal": true,
    "remote.SSH.useLocalServer": false,

All good now. Thanks for this, still helpful 4 years later.

@jordantrizz good news :-)

FYI: My .ssh folder is shared between Win&WSL. I have it in the expected c:\Users\xxxxxx\.ssh. And then in WSL I have an /etc/fstab entry to bind mount that folder into WSL /mnt/c/Users/xxxxx/.ssh /home/xxxxx/.ssh none bind 0 0 and in my ssh config set HashKnownHosts no because I found it was incompatible between the two OSs.

That's actually a good idea. I don't use anything in Windows aside from VSCode that would use C:\Users\xxxx.ssh

I've always lived in WSL and utilised the WSL .ssh folder, but now I'm thinking it might be better doing it this way. I also use the keychain program in WSL, which doesn't really work with VSCode and I haven't seen if it can work.

I'm also considering just using 1Password ssh-agent with VSCode which would be another solution and skip all of this.

and in my ssh config set HashKnownHosts no because I found it was incompatible between the two OSs.

Interesting, I do enjoy knowing when I'm connecting to a host that is not the host I expected or cloud-init on a vm runs due to an issue.

HashKnownHosts does not prevent that notice. https://man7.org/linux/man-pages/man5/ssh_config.5.html
It only changes the way the hosts are written into ~/.ssh/known_hosts.

Hmmm, a long time ago when I discovered the hash incompat, windows used its own implementation of ssh. But now Windows has an OpenSSH ssh implementation. The hashing might work now. 🤷

HashKnownHosts does not prevent that notice. https://man7.org/linux/man-pages/man5/ssh_config.5.html
It only changes the way the hosts are written into ~/.ssh/known_hosts.

Man, a quick google didn't even describe this properly. I should have just gone to the man page, thank for correcting me! I actually think HashKnownHosts is beneficial incase the data is compromised.

Hmmm, a long time ago when I discovered the hash incompat, windows used its own implementation of ssh. But now Windows has an OpenSSH ssh implementation. The hashing might work now. 🤷

I think I'm only a year into using VScode remote SSH, wish I was using it years ago.

Thanks for the back and forth, hopefully someone finds this useful. Love finding gists like this lol.

I got this working with wsl ssh and keychain!

I have this line in my .bashrc:
eval keychain -q --eval --agents ssh

I then add my key with ssh-add. I usually do this long before I open VS Code because I generally have a terminal open anyway.

I changed the last line to:
C:\Windows\system32\wsl.exe -d dist -u user bash --login -c "%~n0 %v_params%"

dist and user can be changed or they can be removed to use the defaults. My wsl username is not the same as my windows username so I had to use -u.

It now uses my ssh-agent in wsl so I don't have to keep re-entering my ssh key password.