Acessando um repositório mercurial remoto através de um proxy ssh no Windows com tortoisehg

Acessando um repositório mercurial remoto através de um proxy ssh no Windows com tortoisehg

Eu tenho um repositório mercurial remoto (gerenciado pelo hg-gateway) em um servidor. O acesso a esse servidor não está aberto ao público em geral; entretanto, o firewall permite proxy ssh.

Como configuro um cliente Windows para acessar esse repositório com o tortoisehg?

Observe que é diferente deesse, já que nessa questão não há proxy envolvido. Estou procurando o equivalente do Windows

Host remote-dev
    user mercurialuser
    ProxyCommand ssh -q firewalluser@firewall

para acessar um repositório mercurial como

hg clone ssh://remote-dev/repo

Encontrei uma solução funcional e a postarei abaixo nas respostas para o benefício da comunidade.

Responder1

As suposições de administração do sistema estão no final desta postagem.

  1. baixe e instale putty, plink, pageant e puttygen deaqui
  2. se você não tiver uma chave ssh, inicie o puttygen e:
    1. se já tiver uma chave gerada pelo Linux:
      1. selecione 'carregar um arquivo de chave privada existente'
      2. selecione o arquivo apropriado (deve alterar o filtro de extensão de arquivo)
      3. inserir senha
      4. selecione 'salvar chave privada'
    2. outro,
      1. selecione 'gerar chave'
      2. mova o mouse aleatoriamente
      3. selecione 'salvar chave privada'
      4. selecione 'salvar chave pública'
  3. envie ao seu administrador de sistema a CHAVE PÚBLICA e não a chave privada! (administradores de sistemas: leia abaixo)
  4. execute um prompt de comando do Windows (iniciar> executar e digite 'cmd') e inicie 'pageant.exe'
  5. clique com o botão direito no ícone na barra de ícones, 'adicionar chave'
  6. selecione sua chave PRIVADA que você salvou antes, insira a senha
  7. massa de lançamento

    1. into hostname put: o endereço IP do seu servidor de repositório
    2. salve a sessão como ' remote-dev' (qualquer nome está ok)
    3. vá em conexão > proxy
    4. selecione 'local' para o tipo de proxy
    5. nome de host do proxy: sua entrada DNS do firewall ou endereço IP
    6. porta: 22(ou o que for apropriado para fazer ssh no firewall)
    7. nome de usuário: hg(ou qualquer usuário no firewall que tenha sua chave ssh pública em .ssh/authorized_files)
    8. em 'comando telnet ou proxy local' substitua o conteúdo por ' FULLPATH\plink.exe -v -nc %host:%port %user@%proxyhost' (observe o caminho COMPLETO do executável plink.exe. Como c:\plink.exe)
    9. vá em conexão > dados
    10. nome de usuário de login automático: hg (ou qualquer usuário no servidor do repositório que tenha o hg-gateway em execução)
    11. voltar para 'sessão'
    12. clique em 'salvar' para salvar a sessão
    13. clique em 'abrir'
    14. você deveria ver algo como

      Using username "hg".
      Authenticating with public key "imported-openssh-key" from agent
      Welcome to XXX code repository server!
      Your SSH access is restricted by hg-gateway.
      Summary of repos you have access to:
      
  8. agora baixe e instaletartarugahg

  9. lançar bancada de trabalho tartaruga
  10. arquivo> clone repositório
  11. fonte: ssh: // remote-dev/ repo-name(remote-dev deve corresponder ao que você chamou de sessão no PuTTY!)
  12. destino: escolha seu destino local
  13. clique em 'clonar'
  14. é isso.

Para permitir que um usuário acesse o repositório remoto:

  1. adicione a chave ssh pública .ssh/authorized_keysdo usuário hgno firewall
  2. use hg-gatewaypara adicionar a chave desse usuário ao hgusuário no servidor

Uma observação: o putty tende a gerar chaves no formato .ppk; eles precisam ser convertidos em uma chave ssh de uma linha. O Google é seu amigo aqui.

Premissas:

  1. no firewall existe um usuário chamado ' hg' cujo .ssh/autorhized_keysarquivo contém as chaves públicas de todos os usuários que devem acessar o repositório
  2. o arquivo /etc/ssh/sshd_config do firewall contém uma linha semelhante a:

    Match Group dev
        ForceCommand nc -q0 reposerver_ip 22
    

    para que o usuário NÃO possa especificar a quais hosts se conectar. O usuário ' hg' obviamente pertence ao grupo unix ' dev'.

informação relacionada