19

Can I reroute the https traffic (of an svn repository) via ssh-tunnel.

The problem is that the the services that use https don't work if I just create one tunnel for listening with e.g.:

ssh -L 12345:server.com:443 localhost

Do I have to do something else? The aim is to tunnel https://PROJECT.googlecode.com/svn/ where PROJECT is the project name.

Juha
  • 373
  • 2
  • 4
  • 13

3 Answers3

14

HTTPS connection can be redirected via SSH port forwarding - however the SSL/TLS certificate validation will fail in such cases as the host name does not match:

You are connecting to https://localhost:12345 but the server certificate contains the name server.com.

Instead of directly forwarding the HTTPS connection I would run an HTTP(s)/SOCKS proxy on the remote computer you are opening the SSH connection to. Then set-up the program you want to tunnel to use this proxy through port forwarding. This would be a clean solution.

Update: It seems like SVN can use HTTP proxies but not SOCKS proxies. If want to do so you need an additional "socksifier" on your local system. See Serverfault.com: How can I set proxy for subversion with ssh tunnel?

Community
  • 1
Robert
  • 7,357
  • 3
  • 29
  • 48
  • 1
    Can I actually use this kind of approach: http://dltj.org/article/ssh-as-socks-proxy/? So in the googlecode case, I would have a local-computer -> socks-computer -> googlecode. And this "ssh -D" would be run on local computer: ssh -D 12345 [username]@[socks-computer]. Now I have to tell svn to use proxy at local-computer:12345. Do I need something else? – Juha Oct 19 '11 at 11:26
  • Cool, I did not know that OpenSSH already includes a SOCKS proxy. See also my updated answer. – Robert Oct 19 '11 at 11:38
  • 9
    You can get around the HTTPS certificate issue by adding the remote host to your local hosts file with ip address 127.0.0.1. Then you can actually use https://remotehost:12345 address but the traffic will still be directed to SSH tunnel. – Juha Palomäki Aug 14 '13 at 11:44
  • @JuhaPalomäki you should add this as an answer – elhefe Aug 08 '18 at 00:43
3

To be able to work around the certificate DNS mismatch issue while accessing the remote server with SSH tunnel, I did the following:

  1. Configure an SSH tunnel in putty so that local port 443 forwards traffic to the remote server (L443 : <remote.server.com>:443 )
  2. Update C:\Windows\System32\drivers\etc\hosts file to add an entry such as 127.0.0.1 <remote.server.com>
  3. If you are using HTTP proxy server (for example if you are working from a corporate proxy), then bypass the <remote.server.com> host from system proxy
  4. Now you can access the remote server URL with https://<remote.server.com>
Kunal Patil
  • 131
  • 2
  • This solution assumes `putty` and Windows. On Linux SSH is configured in `~/.ssh/config` (doc in `man ssh_config`) and if you are root, you can modify `/etc/hosts` instead. This feels hackish, still. – Stéphane Gourichon Aug 20 '20 at 15:29
  • You can just tell whatever client program you are using to ignore the "bad" certificate. Usually all programs have some options for that (eg. `-k` in `curl`). Since you are setting up tunnel to a well-known server, you can safely ignore warnings about certificate mismatch. – raj Dec 01 '20 at 21:40
2

For Linux one could just SSH dynamic port forwarding

Localhost ssh -fND 1234 user-name@remote-ip-address-A

Remote host ssh -fNL 12345:remote-ip-address-B:443 remote-ip-address-A

Open Firefox install FoxyProxy and set it up as shown in the screengrab. FoxyProxy settings

In Firefox click the FoxyProxy icon and select the proxy connection you just made. In the URL bar type https://127.0.0.1.

Additionally you could just bypass this whole thing and just use sshuttle. Using sshuttle's -H argument causes it to update your local /etc/hosts file as new remote hostnames are found. You will need this so that certificates will work properly.

sshuttle -H -vr user-name@remote-ip-address-A remote-net/ip-address-B
Ned Konz
  • 51
  • 5
BryanC
  • 21
  • 1