2

I have a server that I would like to copy some files to, but I can only access that server via tailscale and only my Windows machine address is registered with that VPN, not my WSL distribution on the machine. So, I cannot directly ssh (or run rsync) from WSL to the server. I can ssh from the Windows machine and I can connect to it (and to the WSL distribution) using vscode (although the file I want to copy is in my WSL home directory not the git repo I normally access on that distribution).

So, I am kind of at a loss as to how to copy the file (it's a tgz file (gzipped tar file), if that makes a difference). It seems there should be a simple way to do it, but it escapes me what it is.

1 Answer 1

1

It seems there should be a simple way to do it

Well, not quite - There are quite a few challenges there, like:

  • Obviously, the fact that WSL2 uses a different IP which won't be accepted by the remote host
  • Potentially, that when connected via VPN, the WSL2 instance may not (depending on VPN configuration) be able to communicate with the Windows portion (or even the network).

Some solutions that I can think of:

  • Of course, the simplest way of doing it would be to first copy the file from the WSL distribution to your Windows home directory with something like (from Bash inside WSL2):

    cp file.tgz /mnt/c/Users/<your_windows_user>/Documents/
    

    ... and then scp then file from Windows to the remote host.

    Of course, there may be good reasons why this might not be desirable, such as the size of the file. Or perhaps the file is being generated in real-time while you are connected to the remote host.

  • A really interesting technique is simply piping the file from WSL to PowerShell, to the SSH command, to the remote host. However, this requires that there be no password challenge during the command - In other words, if you have public key authentication configured (or even can, given that you don't control the remote host), then the following will work from WSL:

    cat filename | powershell.exe -c "ssh user@host 'cat >filename'"
    

    (tested just now with a 21MB .tgz)

    Note that you can't go the opposite direction (using PowerShell to call wsl.exe) since the piping there will corrupt the file with Windows line-endings (also confirmed via that same testing ;-).

  • Another alternative: I keep the Windows OpenSSH server installed on my system for situations like this. I can then use the Windows OpenSSH as a jumphost from WSL2. Something like:

    scp -J windows_username@$(hostname).local filename.tgz remote_name@remote_host:/path/to/filename.tgz
    

    (not tested recently, going from memory and doc)

    Using a jumphost, the remote system will see the connection as coming from the Windows host's IP, rather than the WSL2 IP.

    It should also be possible to use rsync through the SSH connection via jumphost.

    Note also that this assumes that you can connect from WSL2 to the Windows host when the VPN is active. Some VPN systems will disable local connections.

3
  • I wasn't able to get the jumphost option to work, which would have been my preferred method. In fact, I could get ssh forwarding to work at all and I've read several of your answers on getting ssh to work with WSL. I'd eventually like to ssh from WSL to the server, so that I can use port forwarding to run emacs on the server and have WSL handle the X traffic..... In the end, I decided I could live with your first method and copied the file to my windows documents directory and did the scp from there. Commented Sep 16, 2023 at 5:44
  • @ChristopherClark Ah, bummer - Do you think that's because the VPN may be disabling local networks? If that's the case, you could try a WSL1 instance - Networking works differently there and usually works when the VPN is in play. That would at least allow you to run Emacs remotely. You'd need a third-party X-server (e.g., VcXsrv) under WSL1, but before WSLg, we all did anyway ;-) Commented Sep 16, 2023 at 13:35
  • No, I don't think so, because it lets me talk (from windows) to my other laptops on my lan. I think I have a firewall in the way or maybe linux is trying to use port 22. At some point I will figure it out. But WSL1 is an interesting twist. I used that with VcXsrv previously (on a different laptop). I got enough of my Linux environment moved to the server, so this isn't a pressing problem and emacs is working ok through ssh and screen. Reminds me of cygwin days.... Commented Sep 16, 2023 at 17:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .