Como faço para o SSH maquinar A via B em um comando?

Question

Eu quero acessar um computador, digamos máquina A que é baseado na rede da minha universidade. No entanto, este computador só é acessível através da rede interna da universidade, por isso não posso usar o SSH para este computador diretamente de casa.

Veja o que faço agora:

1. Faça login em uma máquina universitária diferente, digamos máquina B

   (Esta máquina B é acessível via SSH do meu computador de casa.)

2. Use SSH em B para se conectar a A.

Existe uma maneira de fazer isso mais rápido? Usando apenas um comando ssh.

    

Answer 1

Sim, usando ProxyCommand na configuração do SSH.

Crie um arquivo de configuração SSH em seu diretório pessoal (a menos que você queira fazer isso em todo o sistema), ~/.ssh/config :

Host unibroker          # Machine B definition (the broker)
Hostname 12.34.45.56    # Change this IP address to the address of the broker
User myusername         # Change this default user accordingly 
                        # ('user@unibroker' can overwrite it)

Host internalmachine    # Machine A definition (the target host)
ProxyCommand ssh -q unibroker nc -q0 hostname.or.IP.address.internal.machine 22

Agora você pode acessar a Máquina A diretamente usando

ssh user@internalmachine

Observe também que agora você tem um único nome de destino de host SSH para ele, você pode usá-lo em outros aplicativos também. Por exemplo:

• SCP para copiar arquivos.

  scp somefile user@internalmachine:~/
  

• Em seus aplicativos GUI:

  use sftp://user@internalmachine/ como o local para navegar na máquina.

  Baseado no KDE (Dolphin): use fish://user@internalmachine/

Notas

Altere hostname.or.IP.address.internal.machine e a porta ( 22 ) para a máquina que você deseja acessar como se fosse da máquina unibroker .

Dependendo das versões do netcat no host unibroker, a opção -q0 deve ser omitida. Em relação à autenticação; basicamente você está configurando duas conexões SSH da sua estação de trabalho. Isso significa que o host unibroker e o host internalmachine são verificados / autenticados em relação a um após o outro (para verificação de chave / senha e chave de host).

Explicação

Essa abordagem do uso de ProxyCommand e 'netcat' é apenas uma maneira de fazê-lo. Eu gosto disso, porque meu cliente SSH fala diretamente com a máquina de destino para que eu possa verificar a chave do host do meu cliente e eu posso usar minha autenticação de chave pública sem usar outra chave no broker.

Cada Host define o início de uma nova seção do host. Hostname é o nome de host ou endereço IP de destino desse host. User é o que você forneceria como a parte do usuário em ssh user@hostname .

ProxyCommand será usado como o pipe para a máquina de destino. Usando o SSH na primeira máquina e configurando diretamente um 'netcat' simples ( nc ) para o destino a partir daí, este é basicamente apenas um texto simples encaminhado para a máquina interna do intermediário entre eles. As opções -q são para silenciar qualquer saída (apenas uma preferência pessoal).

Certifique-se de ter o netcat instalado no broker (geralmente disponível por padrão no Ubuntu) - netcat-openbsd < img src="https://hostmar.co/software-small"> ou netcat-traditional < img src="https://hostmar.co/software-small"> .

Note que você ainda está usando o SSH com criptografia duas vezes aqui. Enquanto o canal netcat é texto plano, o seu cliente SSH no seu PC irá configurar outro canal criptografado com a máquina final de destino.

    

Answer 2

Pule de uma só vez

Uma alternativa óbvia para a abordagem ProxyCommand que eu forneci em minha outra resposta seria 'pular' diretamente para a máquina alvo :

ssh -t user@machineB ssh user@machineA

Observe o comando -t no primeiro ssh . Sem isso, irá falhar:

Pseudo-terminal will not be allocated because stdin is not a terminal.
ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
Permission denied, please try again.
[...]

Isso forçará um TTY real a ser alocado

A desvantagem disso é que agora toda a configuração, verificação e autenticação ocorrem na Máquina B, o que eu realmente não gosto na minha situação por razões de segurança. Eu gosto do meu par de chaves no meu próprio PC e autentico e verifico a máquina alvo final do meu próprio PC. Além disso, você só pode usar o shell interativo para SSH, portanto, isso não lidará com outras ferramentas, como o SCP, nem com o gerenciador de arquivos da GUI.

Por todas as razões citadas, eu recomendo strongmente a abordagem ProxyCommand , mas para uma conexão rápida, isso funciona bem.

    

Answer 3

Tente usar

Host <visible hostname alias>
        Controlmaster auto
        User <user>
        hostname <visible hostname>
        port <port>
        IdentityFile ~/.ssh/<id file>

Host <private LAN hostname alias>
     ProxyCommand ssh -q -W <private LAN hostname>:<private LAN port> <visible hostname alias>

no seu ~ / .ssh / config e faça tudo de uma vez só com as chaves residentes no seu computador.

    

Answer 4

Você pode usar a opção de linha de comando -J :

ssh -J user@machineB user@machineA

Em man ssh :

-J [user@]host[:port]
     Connect to the target host by first making a ssh connection to
     the jump host and then establishing a TCP forwarding to the
     ultimate destination from there.  Multiple jump hops may be
     specified separated by comma characters.  This is a shortcut to
     specify a ProxyJump configuration directive.

Foi introduzido na versão 7.3 do OpenSSH (lançada em agosto de 2016). Está disponível no Ubuntu 16.10 e posterior.

    

Answer 5

O ProxyCommand é uma solução limpa para um caso quando você permite o acesso ao shell em ambos os sistemas. Queríamos dar aos usuários remotos acesso a uma máquina interna (A) por meio de um intermediário (B), mas sem permitir que o usuário tivesse acesso ao shell B para melhorar a segurança. Isso funcionou:

Substitua o shell de login

Substitua o shell de login (use chsh ) para extuser no broker pelo seguinte script (armazenado em um arquivo):

#!/bin/sh   # this is essential to avoid Exec format error
ssh internaluser@A

Desde que nenhum login de senha tenha sido configurado no extuser @ B para o usuário remoto e no internaluser @ A para o extuser @ B, a execução do comando a seguir levará o usuário remoto diretamente para A

ssh extuser@B

Dica : Crie a configuração necessária de login_do_autor autorizado sem senha no extuser @ B antes de alterar para o shell de login customizado. Após a mudança, uma vez que esta conta é inacessível para qualquer pessoa através de um shell, apenas um sudoer @ B pode fazer alterações no arquivo authorized_keys editando-o diretamente.

sudo vi ~extuser/.ssh/authorized_keys
sudo touch ~extuser/.hushlogin

A última linha é para suprimir a exibição do banner de login de B, para que o usuário remoto tenha um acesso transparente a A

.     

Answer 6

Esta é uma sugestão muito útil. Depois de brincar por horas, eu encontrei esta nota, & amp; confirmou isso funciona exatamente como documentado. Para conectar-se através do MachineA ao MachineB, a partir do machineC remoto:

exemplo: [xuser @ machineC ~] ssh -t MachineA ssh MachineB

O "-t" é crítico, ssh falha se não estiver presente. Você será avisado duas vezes, primeiro pela senha no MachineA, depois pela segunda vez MachineB. Além disso, observe que isso pressupõe que você tenha o usuário "xuser" definido em todos três máquinas. Se não, use apenas a sintaxe ssh: "yuser @ MachineA ...". Observe também que você pode usar IP # s em ponto quad, se você quiser. Isso é útil se você estiver conectando através de uma rede privada local que está usando IPs não expostos ao mundo - ou seja. não em seu arquivo de host local ou qualquer DNS. Para obter um arquivo do MachineB, para a máquina remota, você pode scp de MachineB para MachineA, depois de MachineA para machineC remoto. (Por exemplo, o O machineC remoto pode fazer ping no MachineA, mas não no MachineB.) Advertência: Eu testei com o Fedora e WindowsXP, MachineA é um ICS (Internet Connection Sharing), enquanto MachineB e remote machineC são caixas Fedora-Linux. Esta sugestão resolveu um problema fundamental para mim - ie. restrito, monitorado acesso remoto ao meu site remoto lan. Note também, quando você "sair" do MachineB, você deve ver dois "Conexão para xxx.xxx.xxx.xxx fechado." mensagens.