Trabajo de conexión SSH a través de Proxy

3

Tengo que configurar el proxy de mi navegador web a 172.18.10.1:3128 cada vez que quiero conectarme a internet desde mi universidad. Dado que estoy configurando el proxy de un navegador web, creo que el proxy es un "Proxy HTTP" y que el servidor proxy puede aceptar la conexión HTTP porque tiene el conocimiento de los encabezados y empaquetadores HTTP.

Ahora, ¿puedo usar este proxy para configurar una conexión SSH? Si es así, ¿cómo funcionaría esta conexión? Mi concepto es que SSH y HTTP tienen diferente estructura de encabezado / paquete porque son dos protocolos diferentes y por esta razón, el servidor proxy HTTP de mi universidad no podría reenviar el tráfico SSH. Por favor, corrígeme si me equivoco.

    
pregunta 7_R3X 10.10.2016 - 00:49
fuente

1 respuesta

3

Usted tiene razón en los diferentes encabezados (a.k.a. banners), y ese simple SSH no atravesará un proxy HTTP. Pero los proxies vienen con métodos de recorrido incorporados, y un proxy HTTP viene con la palabra HTTP CONNECT. Como no está seguro de si es un proxy HTTP o no, también agregaré información sobre los proxies SOCKS.

Hay prácticamente solo 2 tipos de proxies: HTTP o SOCKS (otros proxies son a menudo solo hacks juntos). 3128 es un puerto estándar (más o menos) para el proxy de calamar, por lo que es muy probable que sea el software que se utiliza para crear el proxy. Y squid puede ejecutar proxies HTTP o SOCKS.

Tanto Firefox como Chrome tienen la configuración de usar el proxy como un proxy HTTP o un proxy SOCKS. Está escrito junto a la opción donde ingresa la dirección del proxy. Si ambos funcionan, entonces Squid está configurado para aceptar ambos.

De cualquier manera, SSH se puede configurar usando ProxyCommand para usar ese comando para atravesar un proxy. Pero aún necesita un comando que sea capaz de atravesar el proxy en sí. Hay varias opciones, mi favorito es ncat (el programa netcat que se proporciona con NMAP) y lo usaré en el siguiente ejemplo, pero agregaré más opciones al final de la respuesta.

Dentro de tu ~/.ssh/config puedes agregar

ProxyCommand /usr/bin/ncat --proxy-type http --proxy 172.18.10.1:3128 %h %p

Donde --proxy-type también puede ser socks4 o socks5 . SSH utilizará ese comando para atravesar el proxy y luego establecer la conexión.

Otras opciones

También se puede utilizar Plain nc, de la siguiente manera:

ProxyCommand /usr/bin/ncat -X connect -x 172.18.10.1:3128 %h %p

Y para SOCKS, los argumentos -X deben ser "4" (SOCKSv4) o "5" (SOCKSv5). Desafortunadamente, nc varía de una plataforma a otra y es posible que algunas opciones no estén disponibles.

Si aún tiene un firewall después del proxy, consulte Gilles's contesta en unix.SE para obtener una bolsa adicional de trucos.

Nota adicional

Puedes desactivar HTTP CONNECT en squid. Y si está deshabilitado, todas las apuestas están desactivadas, ya que el proxy no permitirá que ningún tráfico que no sea una PALABRA HTTP válida (que no esté deshabilitada, por ejemplo, GET, POST) lo atraviese.

Sin embargo, el gran problema con la desactivación de HTTP CONNECT es que el tráfico HTTPS no puede atravesar el proxy, por lo que es poco probable que un proxy HTTP tenga HTTP CONNECT desactivado.

Actualización: ¿No puede un proxy simplemente permitir el paso de HTTPS "nativo"?

Esta es una pregunta en el comentario de @Pacerier que encontré que puede ser interesante de abordar. Pregunta completa:

  

¿No puede un firewall permitir HTTPS nativos mientras se bloquea HTTP CONNECT HTTPS?

En el que me involucraré (ya que estamos hablando de proxies realmente):

  

¿Un proxy no puede permitir conexiones HTTPS nativas mientras bloquea HTTP CONNECT HTTPS?

Sí y no. Primero, un proxy no bloquea las conexiones que no pasan por el proxy, solo decide las conexiones que van directamente al proxy. En teoría, un proxy podría permitir el paso de HTTPS "nativo", el problema es que el HTTPS "nativo" es básicamente cualquier flujo de bytes , ya que está cifrado a nivel de TCP. En otras palabras, HTTPS no es un protocolo que se vea al mirar los paquetes, es decir, por diseño.

El argumento contrario sería que un proxy sería capaz de verificar si una secuencia realiza el protocolo de enlace HTTPS al principio y, si ambos lados "completan" la comunicación, entonces permite que cualquier flujo de bytes continúe a través de estas conexiones . Tenga en cuenta que no se puede saber si las partes conectadas tuvieron éxito en el protocolo de enlace, es decir, también por diseño, por lo tanto, un proxy solo puede saber si se envió un protocolo de enlace o no.

Suponiendo lo anterior, ahora puede usar su proxy para cualquier protocolo , ya que simplemente puede simular un protocolo de enlace HTTPS y luego enviar lo que desee. Esto anula el propósito de la mayoría de los proxies, es decir, convirtió su proxy OSI layer 7 (HTTP) en un proxy OSI layer 4 (TCP). Y en un proxy de capa 4 ya no importa si está utilizando HTTP, HTTPS, FTP o LDAP.

Referencias (no muy relacionadas pero tomé información de allí)

respondido por el grochmal 10.10.2016 - 02:23
fuente

Lea otras preguntas en las etiquetas