CorkScrew

Utilizando SSH através de um proxy HTTP.

Aviso

Os procedimentos aqui descritos podem ir contra a política da sua empresa. Use por sua conta e risco!

O assunto abordado não é para iniciantes, por isso deixei o passo-a-passo e as explicações básicas para mencionar somente os passos necessários para colocar a solução para funcionar e tem um mínimo de compreensão do que estamos fazendo. No entanto, fique a vontade para deixar suas perguntas através dos comentários.

Cenário

Você está numa rede corporativa, atrás de um proxy autenticado e de regras de firewall e roteamento que só deixam passar pacotes direcionados as portas 80 ou 443 com destino ao servidor proxy.

Sendo assim:

• Não é possível usar um servidor VPN, já que a conexão seria automaticamente redirecionada para o proxy da empresa. Ou então a conexão para o IP ou porta do servidor VPN seria bloqueada.
• Não é possível acessar serviços que não aceitem configuração de proxy.
• Não é possível acessar servidores SSH fora da rede da empresa.

Solução de contorno — Corkscrew

O corkscrew é uma ferramenta que possibilita o tunelamento de conexões SSH através do protocolo HTTP(S). Com isso, é possível estabelecer uma conexão SSH com um servidor externo, passando através do proxy, como se fosse um acesso HTTP(S). O corkscrew aceita, inclusive, proxy autenticado.

Instalando e configurando

Baixe e instale o corkscrew. No Linux é bem provável que exista um pacote pré-compilado para a sua distribuição.

Caso não exista, crie o arquivo ~/.ssh/config com o seguinte trecho:

# ~/.ssh/config
host corkscrew
    hostname sshServerIp
    user sysadmin
    ProxyCommand corkscrew proxyIp proxyPort %h %p

Onde:

• sshServerIp: é o endereço IP do seu servidor SSH.
• proxyIP: é o endereço IP do proxy da sua empresa.
• proxyPort: é a porta utilizada pelo proxy da sua empresa.

Se o proxy da sua empresa exige autenticação, acrescente "~/.ssh/proxyauth" ao final da linha ProxyCommand, com o seguinte conteúdo:

# ProxyCommand corkscrew proxyIp proxyPort %h %p ~/.ssh/proxyauth
     usuarioProxy:senhaProxy

Substitua o usuário e a senha do proxy por credenciais válidas.

Você vai precisar acessar seu servidor SSH e reconfigurá-lo para fazer o sshd escutar na porta 443. Para isso você terá que fazer o acesso de outra rede ou através do 4G do seu celular.

No seu servidor SSH altere o arquivo /etc/ssh/sshd_config, acrescentando a seguinte linha:

# /etc/ssh/sshd_config
Port 443

Não é necessário, nem recomendado remover a linha "Port 22", assim seu servidor SSH continuará escutando na porta padrão também.

Reinicie o serviço responsável pelo SSH, no CentOS7:

systemctl restart sshd

Se estiver utilizando o SELinux, será necessário habilitar o contexto para que o ssh possa trabalhar numa porta diferente.

Também será necessário um proxy instalado no seu servidor SSH. O squid na configuração padrão do CentOS 7 já atende a nossa necessidade:

sudo yum -y install squid
sudo systemctl enable squid
sudo systemctl start squid

Hora de testar. Utilizando a rede da sua empresa, estabeleça uma conexão com seu servidor SSH utilizando o seguinte comando:

ssh -L 8080:localhost:3128 sysadmin@corkscrew -p 443

Estamos estabelecendo uma conexão com corkscerw, definido no arquivo .ssh/config como o seu servidor SSH, utilizando o corkscrew através da opção ProxyCommand. A conexão é feita pela porta 443 e direcionada ao seu proxy, não diretamente ao seu servidor SSH. Pois a porta 443 é uma das portas que geralmente são "confiáveis" pelos servidores de proxy, e o proxy da sua empresa precisa aceitar conexões HTTPS por ela.

Aqui está a mágica, o corkscrew vai tunelar os pacotes SSH, dentro do HTTPS, como se você estivesse acessando um site SSL, mas na verdade é o seu servidor SSH. Já o cliente ssh que você está executando, cria um túnel entre localhost:8080, a porta 8080 da sua estação de trabalho, com a porta 3128 do seu servidor SSH, o qual o corkscrew estabeleceu a conexão SSL através do seu proxy. Brilhante!!!

Agora basta você definir no seu browser o proxy como sendo localhost:8080 que todas as requisições serão redirecionadas para o proxy squid rodando no seu servidor SSH. Para o proxy da sua empresa, você está acessando uma página HTTPS no IP do seu servidor SSH. Mas no fundo você fez um túnel para estabelecer uma conexão SSH e está usando essa conexão SSH para se comunicar com seu proprio proxy, suas regras, … e como o tráfego é sobre HTTPS, sua empresa só registra os acessos ao IP do seu servidor SSH, não sendo possível monitorar quais páginas você está acessando.

Eu só estava interessado em usar o SSH para acessar outros servidores. Mas de quebra ainda ganhei a possilidade de contornar os bloqueios do proxy para acessar meus treinamentos on-line ;-)