SSH Shell via SSH Proxy

3

Sim, estou ciente de que escrevi "shell SSH" no título.

TL; DR: O primeiro parágrafo, aquele com o link e aquele com a mensagem de erro são os mais importantes.

Eu tenho meu Raspberry Pi em casa, que eu posso acessar pela internet, mas somente via IPv6. Atualmente estou em um local onde não tenho IPv6.

Eu posso executar comandos nele primeiro fazendo login em um servidor que tenha IPv4 e IPv6 e, em seguida, faça login no meu pi a partir daí. No entanto, eu uso o SSH nele para mais do que executar comandos nele:

  • git
  • backups (Deja Dup)
  • acessando arquivos (SFTP)
  • VNC (faço o encapsulamento por SSH e posso conectar-me ao host local via VNC)

Estes estão em ordem decrescente de importância. Eu quero acessar meus git repos.

Mais alguns detalhes:

  • Não posso simplesmente tornar meu Pi acessível via IPv4. O modem está atrás tem um endereço IPv4 e uma sub-rede IPv6, mas eu tenho que usar hardware. Eu não escolhi o software em execução que não posso mudar. Esse software não é apenas buggy e eu não posso nem dar uma olhada nele, mas, além disso, ele não permite o envio de todas as portas IPv4.
  • Eu não controlo o servidor com IPv4 e IPv6. Eu só tenho uma conta de usuário normal e não posso - por exemplo - instalar um novo software se mais do que os direitos de usuário padrão forem necessários.

Pesquisando uma solução em esta página bastante promissora , e realmente funciona para o git. Eu configurei novos controles remotos para os repositórios que estou usando, simplesmente substituindo o nome de domínio do pi por localhost:3333 .

Mas parece muito mais promissor do que isso. Parece a solução para todos os itens acima. E meio que começou a dar certo!

O SFTP funciona e não consigo realmente determinar se os backups via Deja Dup funcionam, porque minha conexão é muito lenta, mas ainda não falhou, e algo está causando tráfego de rede, o que é bom e promissor.

Mas por que não posso fazer ssh localhost:3333 para me conectar ao meu laptop para obter uma concha no meu pi? O comando resulta nesta mensagem de erro:

ssh: Could not resolve hostname localhost:3333: Name or service not known

Estou principalmente interessado em saber por que não consigo uma concha da maneira que esperava que funcionasse.

    
por UTF-8 27.12.2016 / 17:26

2 respostas

5

Você pode querer olhar para a configuração ssh do ProxyCommand , o que permite que isso funcione de forma mais perfeita, e funcionará para shells, SFTP, túneis e qualquer outra coisa que você queira para proxy via ssh. / p>

Digamos que você tenha os três hosts a seguir:

  • workstation.example.com - Esta é a máquina em que você está trabalhando fisicamente
  • proxy.example.com - Esta é a máquina para a qual você está roteando seu tráfego SSH através de
  • endpoint.example.com - Aqui é onde você deseja que o tráfego acabe

Em ~/.ssh/config on workstation , adicione o seguinte:

Host endpoint
    User EndpointUser # set this to the username on the destination host
    HostName endpoint.example.com
    ProxyCommand ssh [email protected] nc %h %p 2> /dev/null

No host proxy , certifique-se de que nc (netcat) esteja instalado.

Em seguida, em workstation , você pode ssh endpoint ou sftp endpoint e será transparentemente intermediado por proxy para a máquina por meio de seu host proxy.

    
por 27.12.2016 / 17:34
0

Existem algumas peças que podem ser reunidas de diferentes maneiras, dependendo do que funciona melhor para você. Cada peça é opcional e tem variantes.

Vou usar os seguintes termos:

  • "área de trabalho" = > a máquina na qual você está sentado (no seu exemplo, aquela com ipv4).
  • "host de salto" = > a máquina no meio, a que você tem que passar (no seu exemplo, com ipv4 & ipv6)
  • "target" = > a máquina final na qual você realmente quer estar (no seu caso, o Pi).

    1. considere o uso de chaves ssh, em vez de senhas. Isso economizará muito tempo digitando senhas. Veja link
    2. Certifique-se de que você pode ssh diretamente para o jumphost com 'ssh jumphostname' ou 'ssh jumpuser @ jumphostname' - se houver outras opções que você precisar conectar (número da porta etc), adicione uma entrada ao seu ~ / .ssh / config para este jumphost.
    3. Adicione uma entrada ao ~ / .ssh / config para o destino, com uma cláusula 'ProxyJump jumphostname' ou 'ProxyJump jumpuser @ jumphostname'.
    4. Se você acessa o alvo algumas vezes diretamente e às vezes por meio de um jumphost (por exemplo, 'desktop' é um laptop que às vezes você usa em casa e às vezes no trabalho), pode dar um nome diferente ao alvo e / ou jumphost ex. 'Host jump-pi' ou 'Host jump-proxy'), e especifique o nome do host ou ip real do destino na cláusula 'hostname'.
    5. Agora você deve poder fazer o ssh diretamente da sua área de trabalho para o pi. Nos bastidores, o ssh criará uma conexão da sua área de trabalho com o host de salto e, em seguida, iniciará outra conexão diretamente da sua área de trabalho através dessa primeira conexão até o destino.
    6. Você pode adicionar encaminhamentos de porta ao comando ssh (ou adicioná-lo à sua configuração ssh). Por exemplo, se você quiser que seu pi possa acessar o ssh em sua área de trabalho, escolha uma porta para escutar no pi (selecionarei 2222) e execute os comandos da seguinte forma: "ssh -R2222: localhost: 22 piusername @pi "- isto diz, depois que o ssh se conecta, quaisquer conexões de entrada para a porta 2222 (no pi), devem ser encaminhadas de volta através do túnel para a sua área de trabalho, que deve então se conectar à" porta localhost 22 ". Então, no pi, você pode "ssh -p 2222 desktopuser @ localhost". Você pode fazer o mesmo para qualquer outra porta única (desde que você possa especificar o nome do host e a porta do programa que está usando).
    7. Se você quiser ter uma rede geral, poderá executar o Dynamic Socks. O ssh tem isso embutido, mas só funciona na direção OUTRA. Para permitir conexões indo BACK (do Pi para o seu desktop), você precisará de um servidor Dynamic Socks em seu desktop. Em seguida, configure uma conexão tcp do servidor Pi para o Dynamic Socks (conforme a etapa 6) e, em seguida, execute um cliente Dynamic Socks no Pi (alguns aplicativos têm Dynamic Socks embutidos, por exemplo, wget ou você pode usar algo como 'tsocks' ').
    8. Se isso não for genérico o suficiente, execute o PPP sobre o ssh. Isto lhe dará outra "placa de rede" tanto na sua área de trabalho quanto no Pi, eles poderão conversar diretamente entre si. Você pode configurar o roteamento através desta interface (tenha cuidado, se você perder a conectividade com o Pi, você não poderá consertá-lo remotamente).
por 03.10.2018 / 23:54