¿Cómo hago SSH para maquinar A a través de B en un comando?

Quiero acceder a una computadora, por ejemplo, la máquina A, que se basa en la red de mi universidad. Sin embargo, esta computadora solo es accesible a través de la red interna de la universidad, por lo que no puedo usar SSH en esta computadora directamente desde mi casa.

Esto es lo que hago ahora:

1. Inicie sesión en una máquina universitaria diferente, digamos máquina B

   (Se puede acceder a esta máquina B a través de SSH desde la computadora de mi casa).

2. Use SSH en B para conectarse a A.

¿Hay alguna manera de hacerlo más rápido? Usando solo un comando ssh.

Sí, usando ProxyCommanden su configuración SSH.

Cree un archivo de configuración SSH en su directorio de inicio (a menos que quiera hacer esto en todo el 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

Ahora puede llegar a la Máquina A directamente usando

ssh user@internalmachine

También tenga en cuenta que ahora tiene un único nombre de destino de host SSH para él, también puede usarlo en otras aplicaciones. P.ej:

• SCP para copiar archivos.

  scp somefile user@internalmachine:~/
  

• En sus aplicaciones GUI:

  utilizar sftp://user@internalmachine/como ubicación para navegar en la máquina.

  Basado en KDE (Dolphin): uso fish://user@internalmachine/

Notas

Cambie hostname.or.IP.address.internal.machiney el puerto ( 22) a la máquina que desea alcanzar como si fuera desde la unibrokermáquina.

Dependiendo de las versiones de netcat en el host unibroker, la -q0opción debe omitirse. En cuanto a la autenticación; básicamente está configurando dos conexiones SSH desde su estación de trabajo. Esto significa que tanto el host del unibroker como el host de la máquina interna se verifican / autentican uno tras otro (tanto para el par de claves / contraseña como para la verificación de la clave del host).

Explicación

Este enfoque del uso de ProxyCommandy 'netcat' es solo una forma de hacerlo. Me gusta esto, porque mi cliente SSH habla directamente con la máquina de destino para que pueda verificar la clave de host de mi cliente y puedo usar mi autenticación de clave pública sin usar otra clave en el intermediario.

Cada uno Hostdefine el inicio de una nueva sección de host. Hostnamees el nombre de host de destino o la dirección IP de ese host. Useres lo que proporcionaría como parte del usuario ssh user@hostname.

ProxyCommandse utilizará como tubería para la máquina de destino. Al usar SSH en la primera máquina y configurar directamente un 'netcat' ( nc) al objetivo desde allí, esto es básicamente un texto sin formato hacia la máquina interna desde el intermediario entre ellos. Las -qopciones son silenciar cualquier salida (solo una preferencia personal).

Asegúrese de tener netcat instalado en el agente (generalmente disponible de forma predeterminada en Ubuntu), ya sea netcat-openbsd o netcat-traditional .

Tenga en cuenta que todavía está utilizando SSH con cifrado dos veces aquí. Si bien el canal netcat es de texto sin formato, su cliente SSH en su PC configurará otro canal cifrado con la máquina de destino final.

Salta de una vez

Una alternativa obvia al enfoque de ProxyCommand que proporcioné en mi otra respuesta sería 'saltar' directamente a la máquina de destino:

ssh -t user@machineB ssh user@machineA

Tenga -ten cuenta el en el primer sshcomando. Sin ella, fallará:

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.
[...]

Obligará a que se asigne un TTY real

La desventaja de esto es que ahora toda la configuración, verificación y autenticación se lleva a cabo en la Máquina B, lo que realmente no me gusta en mi situación por razones de seguridad. Me gusta mi par de llaves en mi propia PC y autenticar y verificar la máquina de destino final desde mi propia PC. Además, solo puede usar el shell interactivo para SSH, por lo que no se ocupará de otras herramientas como SCP o el uso de su administrador de archivos GUI.

Por todas las razones antes mencionadas, recomiendo encarecidamente el enfoque ProxyCommand , pero para una conexión rápida, esto funciona bien.

Puede usar la -Jopción de línea de comando:

ssh -J user@machineB user@machineA

De 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.

Se introdujo en OpenSSH versión 7.3 (lanzado en agosto de 2016). Está disponible en Ubuntu 16.10 y posterior.

Intenta 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>

en tu ~ / .ssh / config y hazlo todo de una vez con las claves que solo residen en tu computadora.

Esta es una sugerencia muy útil. Después de jugar durante horas, encontré esta nota y confirmó que funciona exactamente como se documenta. Para conectar a través de la máquina A a la máquina B, desde la máquina remota C:

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

El "-t" es crítico, ssh falla si no está presente. Se le solicitará dos veces, primero la contraseña en MachineA, luego la segunda en MachineB. Además, tenga en cuenta que esto supone que tiene el usuario "xuser" definido en las tres máquinas. Si no, simplemente use la sintaxis ssh: "yuser @ MachineA ...". También tenga en cuenta que, si lo desea, puede usar IP # s sin procesar con cuatro puntos. Esto es útil si se conecta a través de una red local privada que utiliza IP que no están expuestas al mundo, es decir. no en su archivo de host local ni en ningún DNS. Para obtener un archivo de MachineB, a machineC remoto, puede scp de MachineB a MachineA, luego de MachineA a machineC remoto. (Por ejemplo, la máquina remota C puede hacer ping a la máquina A, pero no a la máquina B.) Advertencia: probé con Fedora y Windows XP, MachineA es un XP-box que ejecuta ICS (Conexión compartida a Internet), mientras que MachineB y machineC remota son cajas Fedora-Linux. Esta sugerencia resolvió un problema clave para mí, es decir. acceso remoto restringido y monitoreado a mi sitio remoto lan. Tenga en cuenta también que cuando "cierre sesión" desde MachineB, debería ver dos "Conexión a xxx.xxx.xxx.xxx cerrada". mensajes

ProxyCommand es una solución limpia para un caso en el que permite el acceso de shell en ambos sistemas. Queríamos dar a los usuarios remotos acceso a una máquina interna (A) a través de un intermediario (B), pero sin permitirle al usuario un acceso de shell a B para mejorar la seguridad. Esto funcionó:

Reemplace el shell de inicio de sesión

Reemplace el shell de inicio de sesión (uso chsh) para extuseren el intermediario con el siguiente script (almacenado en un archivo):

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

Siempre que no se haya configurado un inicio de sesión con contraseña en extuser @ B para el usuario remoto y en internaluser @ A para extuser @ B, la ejecución del siguiente comando llevará directamente al usuario remoto a A

ssh extuser@B

Consejo : Cree la configuración necesaria de inicio de sesión sin contraseña autor_keys en extuser @ B antes de cambiar al shell de inicio de sesión personalizado. Después del cambio, dado que esta cuenta es inaccesible para cualquiera a través de un shell, solo un sudoer @ B puede realizar cambios en el archivo autorizado_claves editándolo directamente.

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

La última línea es suprimir la pantalla de inicio de sesión de B, para que el usuario remoto tenga un acceso transparente a A.

Quieres decir que necesitas varios puentes :)

Recientemente, encontré este problema con jumper1 jumper2 y mi máquina final, en cuanto a mi sol

script local:

#!/bin/bash
sshpass -p jumper1Passwd ssh -t jumper1@jumper1IP ./Y00.sh

Luego, en el primer puente (que es mi enrutador), coloqué un script llamado Y00.sh:

ssh -tt jumper2@jumper2 -i ~/.ssh/id_rsa sshpass -p finalPassWord ssh -tt final@final

Puede reemplazarlos con su IP y contraseñas, ¡buena suerte!