Funzionamento della connessione SSH tramite proxy

3

Devo configurare il proxy del mio browser Web su 172.18.10.1:3128 ogni volta che desidero connettermi a Internet dal mio college. Dal momento che sto configurando un proxy di un browser Web, credo che il proxy sia un "Proxy HTTP" e il server proxy sia in grado di accettare la connessione HTTP perché ha la conoscenza delle intestazioni HTTP e dei programmi di compressione.

Ora, posso usare questo proxy per configurare una connessione SSH? Se sì, come funzionerebbe questa connessione? Il mio concetto è che SSH e HTTP hanno una struttura header / pacchetto diversa perché sono due protocolli diversi e per questo motivo il server proxy HTTP del mio college non sarebbe in grado di inoltrare il traffico SSH. Per favore correggimi se sbaglio.

    
posta 7_R3X 10.10.2016 - 00:49
fonte

1 risposta

3

Sei corretto sui diversi header (a.k.a. banners), e quel semplice SSH non attraverserà un proxy HTTP. Ma i proxy sono dotati di metodi di attraversamento incorporati e un proxy HTTP viene fornito con la parola HTTP CONNECT. Dato che non sei sicuro se sia o meno un proxy HTTP, aggiungerò anche informazioni sui proxy SOCKS.

Ci sono praticamente solo 2 tipi di proxy là fuori: HTTP o SOCKS (altri proxy sono spesso solo gli hack messi insieme). 3128 è una porta (più o meno) standard per il proxy calamaro, quindi è altamente probabile che sia il software utilizzato per creare il proxy. E squid può eseguire proxy HTTP o SOCKS.

Sia Firefox che Chrome hanno impostato l'utilizzo del proxy come proxy HTTP o proxy SOCKS. È scritto accanto all'opzione in cui inserisci l'indirizzo del proxy. Se entrambi funzionano, allora Squid è configurato per accettare entrambi.

In ogni caso, SSH può essere configurato usando ProxyCommand per usare quel comando per attraversare un proxy. Ma hai ancora bisogno di un comando che sia in grado di attraversare il proxy stesso. Ci sono diverse opzioni là fuori, il mio preferito è ncat (il programma netcat fornito con NMAP) e lo userò nell'esempio qui sotto, ma aggiungerò altre opzioni alla fine della risposta.

All'interno di ~/.ssh/config puoi aggiungere

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

Dove --proxy-type può anche essere socks4 o socks5 . SSH utilizzerà questo comando per attraversare il proxy e quindi stabilire la connessione.

Altre opzioni

Plain nc può anche essere usato, come segue:

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

E per SOCKS gli argomenti -X dovrebbero essere "4" (SOCKSv4) o "5" (SOCKSv5). Sfortunatamente, nc varia da piattaforma a piattaforma e alcune opzioni potrebbero non essere disponibili.

Se hai ancora un firewall dopo il proxy vedi Gilles's rispondi a unix.SE per un ulteriore bagaglio di trucchi.

Nota aggiuntiva

È possibile disabilitare HTTP CONNECT in squid. E se questo è disattivato tutte le scommesse sono disattivate, poiché il proxy non consentirà alcun traffico che non sia una WORD HTTP valida (che non sia disabilitata, ad esempio GET, POST) dal suo attraversamento.

Tuttavia, il grosso problema con la disattivazione di CONNECT HTTP è che il traffico HTTPS non può attraversare il proxy, pertanto è improbabile che un proxy HTTP abbia disattivato CONNECT HTTP.

Aggiornamento: un proxy non può consentire semplicemente il passaggio HTTPS "nativo"?

Questa è una domanda nel commento di @Pacerier che ho trovato potrebbe essere interessante da affrontare. Domanda completa:

Can't a firewall allow native HTTPS while blocking HTTP CONNECT HTTPS?

Su cui userò (dato che stiamo parlando di proxy in realtà):

Can't a proxy allow native HTTPS connections while blocking HTTP CONNECT HTTPS?

Sì e no. Primo, un proxy non blocca le connessioni che non passano attraverso il proxy, decide solo sulle connessioni che vanno direttamente al proxy. In teoria un proxy potrebbe consentire al HTTPS "nativo" di passare attraverso, il problema è che HTTPS "nativo" è fondamentalmente qualsiasi flusso di byte poiché è crittografato a livello TCP. In altre parole, HTTPS non è un protocollo visibile osservando i pacchetti, ovvero in base alla progettazione.

L'argomento del contatore sarebbe che un proxy sarebbe in grado di controllare se un flusso esegue l'handshake HTTPS all'inizio e, se entrambe le parti "completano" l'handshake, allora consentire a qualsiasi flusso di byte di continuare a passare attraverso queste connessioni . Nota che non è possibile sapere se le parti di collegamento hanno avuto successo nell'handshake, che è anche di progettazione, quindi un proxy può solo sapere che è stata inviata o meno una stretta di mano.

Supponendo quanto sopra, ora puoi usare il tuo proxy per qualsiasi protocollo dal momento che puoi semplicemente simulare un handshake HTTPS e poi inviare quello che vuoi. Ciò vanifica lo scopo della maggior parte dei proxy, ovvero hai trasformato il tuo proxy OSI layer 7 (HTTP) in un proxy OSI layer 4 (TCP). E su un proxy layer 4 non importa più se stai usando HTTP, HTTPS, FTP o LDAP.

Riferimenti (non molto correlati ma ho preso alcune informazioni da lì)

risposta data 10.10.2016 - 02:23
fonte

Leggi altre domande sui tag