SSH através de proxy HTTP com saca-rolhas

Question

Estou encontrando um problema de conexão de um terminal Cygwin para o meu Raspberry Pi doméstico com SSH por trás de um proxy HTTP. Usou-to-work ™ e eu não sei o que mudou desde alguns dias atrás (talvez a filtragem de proxy?). Ainda consigo me conectar de fora da rede proxy sem o saca-rolhas.

Em termos de cliente, meu ssh-config é o seguinte:

Host *
        ServerAliveInterval 60
        ProxyCommand /bin/corkscrew http.proxy.here 80 %h %p

E a tentativa de conexão dá isto:

blx@proxyed-pc:~$ ssh [email protected] -v
OpenSSH_7.9p1, OpenSSL 1.0.2p  14 Aug 2018
debug1: Reading configuration data /home/blx/.ssh/config
debug1: /home/blx/.ssh/config line 1: Applying options for *
debug1: Executing proxy command: exec /bin/corkscrew http.proxy.here 80 my.home.ip 22
debug1: identity file /home/blx/.ssh/id_rsa type -1
debug1: identity file /home/blx/.ssh/id_rsa-cert type -1
debug1: identity file /home/blx/.ssh/id_dsa type -1
debug1: identity file /home/blx/.ssh/id_dsa-cert type -1
debug1: identity file /home/blx/.ssh/id_ecdsa type 2
debug1: identity file /home/blx/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/blx/.ssh/id_ed25519 type -1
debug1: identity file /home/blx/.ssh/id_ed25519-cert type -1
debug1: identity file /home/blx/.ssh/id_xmss type -1
debug1: identity file /home/blx/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
ssh_exchange_identification: Connection closed by remote host

Em termos de servidor, o / var / log / auth relata isso:

Nov 26 13: 39:36 raspi sshd[19130]: debug1: Forked child 19699.
Nov 26 13: 39:36 raspi sshd[19699]: debug1: Set /proc/self/oom_score_adj to 0
Nov 26 13: 39:36 raspi sshd[19699]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Nov 26 13: 39:36 raspi sshd[19699]: debug1: inetd sockets after dupping: 3, 3
Nov 26 13: 39:36 raspi sshd[19699]: debug1: getpeername failed: Transport endpoint is not connected
Nov 26 13: 39:36 raspi sshd[19699]: debug1: ssh_remote_port failed

Assim, a conexão TCP parece estar quebrada, mas não pareço ter esse problema quando tento conectar diretamente com saca-rolhas (por exemplo, $corkscrew http.proxy.here 80 my.home.ip 22 ):

Nov 26 13: 39:32 raspi sshd[19130]: debug1: Forked child 19698.
Nov 26 13: 39:32 raspi sshd[19698]: debug1: Set /proc/self/oom_score_adj to 0
Nov 26 13: 39:32 raspi sshd[19698]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Nov 26 13: 39:32 raspi sshd[19698]: debug1: inetd sockets after dupping: 3, 3
Nov 26 13: 39:32 raspi sshd[19698]: Connection from http.proxy.here port 28220 on 192.168.0.11 port 22
Nov 26 13: 39:32 raspi sshd[19698]: Did not receive identification string from http.proxy.here port 28220

Mas é claro que o sshd não sabe o que fazer com isso ...

Alguma dica? Desde que eu não acho que mudei nada na minha configuração, suspeito de uma atualização furtiva da política de filtragem de proxy que me coloca em esta situação, mas não tenho como ter certeza. Vou tentar atualizar meu roteador e Pi para usar a porta 443 quando chegar em casa.

    

Answer 1

precisamos concordar que não há intenção de contornar algumas medidas de segurança e que conectar dessa forma não é uma violação de qualquer contrato / acordo, é claro. Pseudo-legal disclaimer feito, se eu fosse você eu realmente tente mudar meu servidor para ouvir conexões SSH na porta 443 melhor do que qualquer outro, se passando por um proxy da web. Razões simples:

• Embora as comunicações na porta 80 (tráfego normal da web) não sejam criptografadas e, na maioria das vezes, sejam texto sem formatação (ao ler uma página), a porta 443 é para comunicações criptografadas por SSL. Um proxy não ficará surpreso ao ver as comunicações em formato binário por meio dessa porta. Você precisa de uma conexão binária para o SSH, não como uma página da Web.
• Você não está expondo seu servidor ao público (se você não tiver um firewall de lista branca de IPs do outro lado) com uma porta comumente conhecida como 22. Um novo servidor on-line dura por vezes até mesmo menos de 5 minutos . Então alguém de algum lugar tentará fazer o login via SSH, se eles virem a porta 22 aberta. A porta 443 não adiciona muito mais segurança, mas pelo menos é um pouco menos óbvia do que 22. Boa sorte!