Как SSH обрабатывать A через B одной командой?

Хоп за один раз

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

ssh -t user@machineB ssh user@machineA

Обратите внимание на -t в первой команде ssh. Без этого он будет терпеть неудачу:

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 быть выделенным

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

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

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

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 и сделайте все за один снимок с помощью ключей, которые находятся только на вашем компьютере.

Вы можете использовать опцию командной строки -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 и более поздних версиях.

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

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

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

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

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

ssh extuser@B

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

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

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

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

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

«-t» имеет решающее значение, ssh терпит неудачу, если его нет. Вы получите запрос дважды, сначала для пароля на MachineA, затем второй раз для MachineB. Кроме того, обратите внимание, что это предполагает, что пользователь «xuser» определен на всех трех машинах. Если нет, просто используйте синтаксис ssh: «yuser @ MachineA ...». Также обратите внимание, что вы можете использовать dotted quad raw IP # s, если хотите. Это полезно, если вы связываетесь через частную локальную сеть, которая использует IP-адреса, не подверженные действию в мире, т.е. не в вашем локальном файле хоста, ни в любом DNS. Чтобы получить файл с MachineB, на удаленный machineC, вы можете scp от MachineB до MachineA, а затем от MachineA до удаленного machineC. (Например, удаленный machineC может ping MachineA, но не MachineB.) Предостережение: я тестировал с Fedora и WindowsXP, MachineA - это XP-box, на котором работает ICS (общий доступ к подключению к Интернету), а MachineB и удаленный machineC - это коробки Fedora-Linux. Это предложение решило для меня ключевую проблему - т.е. ограниченный, контролируемый удаленный доступ к моему удаленному языку сайта. Также обратите внимание, что когда вы выходите из MachineB, вы должны увидеть два «Соединение с xxx.xxx.xxx.xxx закрыто». сообщения.