Как я могу SSH к машине A через B в одной команде?

ProxyCommand - это чистое решение для случая, когда вы разрешаете доступ к оболочке в обеих системах. Мы хотели предоставить удаленным пользователям доступ к внутренней машине (A) через посредника (B), но без предоставления пользователю доступа к оболочке B для повышения безопасности. Это сработало:

Замените оболочку входа в систему

Замените оболочку входа в систему (используйте chsh) для extuser на брокере следующим скриптом (сохраненным в файле):

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

При условии, что в extuser @ B для удаленного пользователя не задан пароль для входа в систему, а в extuser @ B для Internaluser @ A, тогда выполнение следующей команды приведет к тому, что удаленный пользователь будет переведен в A

Подсказка : Создайте необходимую настройку без пароля для входа в систему authorized_keys в extuser @ B, прежде чем переходить на пользовательскую оболочку входа. После внесения изменений, поскольку эта учетная запись недоступна кому-либо через оболочку, только sudoer @ B может внести изменения в файл authorized_keys, отредактировав его напрямую.

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

Последняя строка должна подавить отображение баннера входа в систему B, чтобы удаленный пользователь имел прозрачный доступ к A.

Прыжок за один раз

Очевидной альтернативой подходу ProxyCommand, который я представил в , моим другим ответом было бы «прыгать» прямо к целевой машине:

ssh -t user@machineB ssh user@machineA

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

Это приведет к тому, что будет выделен реальный TTY

Недостатком этого является то, что теперь вся конфигурация, проверка и аутентификация происходит на машине B, которая Мне действительно не нравится в моей ситуации по соображениям безопасности. Мне нравится моя пара ключей на моем собственном ПК, и я проверяю и проверяю конечную целевую машину с моего собственного ПК. Кроме того, вы можете использовать только интерактивную оболочку для SSH, поэтому это не касается других инструментов, таких как SCP или вашего файлового менеджера с графическим интерфейсом.

По всем вышеупомянутым причинам я настоятельно рекомендую подход ProxyCommand , но для быстрого подключения это работает нормально.

Попробуйте использовать

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>

в вашем ~ / .ssh / config и сделайте все это за один раз, используя только ключи на вашем компьютере.

Вы имеете в виду, что вам нужно несколько перемычек:)

Недавно я столкнулся с этой проблемой с перемычкой jumper1 и моей конечной машиной, как для моего локального скрипта sol

:

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

Затем на 1-й перемычке (которая является моим маршрутизатором) я поместил скрипт с именем Y00.sh:

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

Вы можете заменить их своими IP-адресами и паролями, удачи!

Это очень полезное предложение. Поработав несколько часов, я нашел эту заметку & amp; подтвердил, что это работает именно так, как задокументировано. Для подключения через MachineA к MachineB с удаленного компьютера C:

, например: [xuser @ machineC ~] ssh -t MachineA ssh MachineB

«-t» имеет решающее значение, ssh завершается ошибкой, если он нет Вам будет предложено дважды, сначала для пароля на MachineA, затем второй раз для MachineB. Также обратите внимание, что это предполагает, что у вас есть пользователь "xuser", определенный на всех трех машинах. Если нет, просто используйте синтаксис ssh: "yuser @ MachineA ...". Также обратите внимание, что при желании вы можете использовать точечные четырехточечные IP-адреса. Это полезно, если вы соединяетесь через частную локальную сеть, которая использует IP-адреса, не представленные миру. не в вашем локальном файле хоста или в любом DNS. Чтобы получить файл с MachineB на удаленный machineC, вы можете перейти с MachineB на MachineA, а затем с MachineA на удаленный machineC. (Например, удаленный компьютер C может пропинговать MachineA, но не MachineB.) Предостережение: Я тестировал с Fedora и WindowsXP, MachineA - это XP-блок с ICS (Internet Connection Sharing), а MachineB и удаленный machineC - это блоки Fedora-Linux. Это предложение решило ключевую проблему для меня - т.е. ограниченный, контролируемый удаленный доступ к моей локальной сети. Также обратите внимание, что когда вы «выходите из системы» из MachineB, вы должны видеть два «Соединение с xxx.xxx.xxx.xxx закрыто». сообщений.

Вы можете использовать опцию командной строки -J:

ssh -J user@machineB user@machineA

Из 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.

Это было введено в OpenSSH версия 7.3 (выпущено в августе 2016 года). Он доступен в Ubuntu 16.10 и более поздних версиях.