Tunnelling git por ssh (para passar por um firewall): especificação de porta interperted como caminho relativo?

Question

Eu tenho acesso ao servidor A via ssh, e do servidor A posso acessar o servidor B, que executa gitlabs e contém o repositório que eu preciso acessar. Quando estou ssh'd no servidor A, posso executar git clone http://serverB/path/to/repo.git com sucesso. Usar ssh:// ou git:// em vez de http:// não funciona. (Erros são "não parece ser um repositório git" e "não é possível conectar ao servidor B," respectivamente).

Se eu configurar um túnel assim:

ssh username@serverA -L 3333:serverB:80 -N

As duas tentativas a seguir nos clones git falham:

git clone http://localhost:3333/path/to/repo.git

Falha com: "fatal: repositório não encontrado"

git clone localhost:3333/path/to/repo.git

Solicita minha senha para serverB e falha com "fatal: 3333 / path / to / repo.git não parece ser um repositório git." Claro que não é! Minha tentativa de especificar localhost, porta 3333, está claramente sendo interpretada como um caminho relativo no serverB.

Existe uma maneira de corrigir isso? Alguma coisa está fundamentalmente errada com essa abordagem?

    

Answer 1

Por que isso não funciona

http://localhost:3333/path/to/repo.git

Isso falha porque o nome do host da URL é diferente ( localhost vs server2 ) e, como resultado, o servidor usa uma configuração diferente.

Todos os clientes HTTP enviam o nome do host solicitado para o servidor, e o servidor pode escolher entre várias configurações (hosts virtuais) com base nesse nome. É assim que muitos sites (geralmente centenas) podem compartilhar o mesmo endereço IP em um provedor de hospedagem.

localhost:3333/path/to/repo.git

Isso falha porque não é uma URL HTTP ou, na verdade, nenhuma URL. (O Git não é um navegador da web e não assume http:// por padrão).

Em vez disso, é um endereço SSH no estilo rcp no formato [user@]host:path . Você pode ter visto isso anteriormente como [email protected]:foo/bar.git , onde o prefixo ssh@ é realmente apenas um nome de usuário SSH.

O Git trata-o como equivalente a ssh://[user@]host[:port]/path URLs, exceto que os endereços no estilo rcp não possuem nenhum campo de porta.

O que fazer

O

curl, o cliente HTTP usado pelo Git, suporta os proxies SOCKS conforme fornecidos pelo ssh -D dynamic tunnel.

1. Configure um túnel dinâmico (SOCKS) com:

   ssh username@serverA -D 1080 -N
   

2. Configure o Git para usá-lo como proxy:

   Globalmente (ou por repositório):

   git config [--global] http.proxy socks5://localhost:1080
   

   Para um único comando:

   git -c http.proxy=socks5://localhost:1080 clone http://serverB/repo.git
   

Os protocolos socks5 e socks4 executam a resolução de DNS no lado do cliente, enquanto socks5h e socks4a transmitem todos os nomes de host por meio de SOCKS para o servidor SSH.