¿Es posible tunelizar el tráfico https a través del túnel ssh con programas ssh estándar?

¿Puedo redirigir el tráfico https (de un repositorio svn) a través de ssh-tunnel.

El problema es que los servicios que usan https no funcionan si solo creo un túnel para escuchar, por ejemplo:

ssh -L 12345:server.com:443 localhost

¿Tengo que hacer otra cosa? El objetivo es hacer un túnel https://PROJECT.googlecode.com/svn/ donde PROYECTO es el nombre del proyecto.

ssh tunnel https

— Juha
fuente

Respuestas:

La conexión HTTPS se puede redirigir a través del reenvío de puertos SSH; sin embargo, la validación del certificado SSL / TLS fallará en los casos en que el nombre de host no coincida:

Se está conectando a https: // localhost: 12345 pero el certificado del servidor contiene el nombre server.com.

En lugar de reenviar directamente la conexión HTTPS, ejecutaría un proxy HTTP (s) / SOCKS en la computadora remota a la que está abriendo la conexión SSH. Luego configure el programa que desea hacer un túnel para usar este proxy a través del reenvío de puertos. Esta sería una solución limpia.

Actualización: Parece que SVN puede usar servidores proxy HTTP pero no servidores proxy SOCKS. Si desea hacerlo, necesita un "calcetín" adicional en su sistema local. Consulte Serverfault.com: ¿Cómo puedo configurar el proxy para la subversión con el túnel ssh?

— Robert
fuente

¿Puedo usar este tipo de enfoque: dltj.org/article/ssh-as-socks-proxy ? Entonces, en el caso de googlecode, tendría una computadora local -> socks-computer -> googlecode. Y este "ssh -D" se ejecutaría en la computadora local: ssh -D 12345 [nombre de usuario] @ [socks-computer]. Ahora tengo que decirle a svn que use proxy en la computadora local: 12345. ¿Necesito algo más?

— Juha

Genial, no sabía que OpenSSH ya incluye un proxy SOCKS. Vea también mi respuesta actualizada.

— Robert

Puede solucionar el problema del certificado HTTPS agregando el host remoto a su archivo de hosts locales con la dirección IP 127.0.0.1. Entonces puede usar la dirección remotehost: 12345 , pero el tráfico seguirá siendo dirigido al túnel SSH.

— Juha Palomäki

@ JuhaPalomäki deberías agregar esto como respuesta

— elhefe

Para poder solucionar el problema de falta de coincidencia de DNS del certificado al acceder al servidor remoto con el túnel SSH, hice lo siguiente:

Configure un túnel SSH en masilla para que el puerto local 443 reenvíe el tráfico al servidor remoto (L443 : <remote.server.com>:443 )
Actualizar C:\Windows\System32\drivers\etc\hostsarchivo para agregar una entrada como127.0.0.1 <remote.server.com>
Si está utilizando un servidor proxy HTTP (por ejemplo, si está trabajando desde un proxy corporativo), omita el <remote.server.com>host del proxy del sistema
Ahora puede acceder a la URL del servidor remoto con https://<remote.server.com>

— KunalP
fuente