web-dev-qa-db-ja.com

1つのコマンドでBを介してマシンAにSSHで接続するにはどうすればよいですか？

machine Aというコンピューターにアクセスしたいのですが、これは私の大学のネットワークに基づいています。ただし、このコンピューターには大学の内部ネットワーク経由でのみアクセスできるため、自宅から直接このコンピューターにSSHを使用することはできません。

私が今やっていることは次のとおりです。

  1. 別の大学のマシンにログインします。たとえば、machine B

    （このマシンBは、自宅のコンピューターからSSH経由でアクセスできます。）

  2. BでSSHを使用してAに接続します。

より速くそれを行う方法はありますか？ 1つのsshコマンドのみを使用します。

networkingsshremote-accesstunnel
101
nikosdi

はい、SSH構成でProxyCommandを使用します。

ホームディレクトリにSSH構成ファイルを作成します（これをシステム全体にしたい場合を除く）、~/.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

これで、マシンAに直接アクセスできます

ssh user@internalmachine

また、単一のSSHホストターゲット名を使用できるようになったことに注意してください。これは他のアプリケーションでも使用できます。例えば。：

  • ファイルをコピーするSCP。

    scp somefile user@internalmachine:~/

  • GUIアプリケーションで：

    sftp://user@internalmachine/をマシンで参照する場所として使用します。

    KDEベース（Dolphin）：fish://user@internalmachine/を使用

ノート

hostname.or.IP.address.internal.machineとポート（22）を、unibrokerマシンからアクセスするように、到達したいマシンに変更します。

Unibrokerホストのnetcatバージョンに応じて、-q0オプションを省略する必要があります。認証に関して基本的に、ワークステーションから2つのSSH接続をセットアップしています。これは、unibrokerホストとinternalmachineホストの両方が次々に検証/認証されることを意味します（キーペア/パスワードとホストキー検証の両方）。

説明

ProxyCommandと 'netcat'を使用するこのアプローチは、その1つの方法にすぎません。 SSHクライアントはターゲットマシンと直接通信するため、クライアントからホストキーを確認でき、ブローカー上の別のキーを使用せずに公開キー認証を使用できるため、これが気に入っています。

各Hostは、新しいホストセクションの開始を定義します。 Hostnameは、そのホストのターゲットホスト名またはIPアドレスです。 Userは、ssh user@hostnameでユーザー部分として提供するものです。

ProxyCommandは、ターゲットマシンへのパイプとして使用されます。最初のマシンにSSHを使用し、そこからターゲットに単純な「netcat」（nc）を直接設定することにより、これは基本的にそれらの間のブローカーから内部マシンに転送されるプレーンテキストです。 -qオプションは、すべての出力を消音します（個人的な好みのみ）。

Netcatがブローカーにインストールされていることを確認してください（通常、Ubuntuではデフォルトで使用可能）- netcat-openbsd Install netcat-openbsd または netcat-traditional Install netcat-traditional 。

ここでは、暗号化を使用してSSHを2回使用していることに注意してください。 netcatチャネルはプレーンテキストですが、PC上のSSHクライアントは最終的なターゲットマシンで別の暗号化されたチャネルを設定します。

96
gertvdijk

一度にホップ

my other answer で提供したProxyCommandアプローチの明らかな代替案は、ターゲットマシンに直接「ホッピング」することです。

ssh -t user@machineB ssh user@machineA

最初のsshコマンドの-tに注意してください。それなしでは、失敗します：

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で行われるようになったことです。これは、セキュリティ上の理由から私の状況ではあまり好きではありません。私は自分のPC上のキーペアが好きで、自分のPCから最終的なターゲットマシンを認証して検証します。また、SSHにはインタラクティブシェルのみを使用できるため、SCPやGUIファイルマネージャーを使用する他のツールを扱うことはできません。

前述のすべての理由から、 ProxyCommandアプローチ を強くお勧めしますが、クイック接続ではこれで問題ありません。

50
gertvdijk

-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年8月にリリース）で導入されました。 Ubuntu 16.10以降で使用できます。

36
Erik Sjölund

使用してみてください

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で、コンピューターにあるキーのみを使用してすべてを一発で実行します。

16
SSH Help

これは非常に役立つ提案です。何時間もいじくり回した後、私はこのメモを見つけ、文書化されたとおりにこれが機能することを確認しました。 MachineAを介してMachineBに接続するには、リモートmachineCから：

例：[xuser @ machineC〜] ssh -t MachineA ssh MachineB

「-t」は重要です。sshが存在しないと失敗します。最初にMachineAでパスワードを入力し、次にMachineBで2回入力するように求められます。また、3つのマシンすべてでユーザー「xuser」が定義されていることを前提としていることに注意してください。そうでない場合は、ssh構文「yuser @ MachineA ...」を使用します。また、必要に応じて、ドット付きクワッドraw IP＃を使用できることに注意してください。これは、世界に公開されていないIPを使用しているプラ​​イベートローカルネットを介してリンクしている場合に役立ちます。ローカルのHostファイルやDNSにはありません。 MachineBからリモートmachineCにファイルを取得するには、MachineBからMachineAに、次にMachineAからリモートmachineCにscpできます。 （たとえば、リモートmachineCはMachineAをpingできますが、MachineBはできません。）警告：私はFedoraとWindowsXPでテストしました。MachineAはICS（インターネット接続共有）を実行するXPボックスです。 Fedora-Linuxボックス。この提案は私にとって重要な問題を解決しました-すなわち。リモートサイトLANへの監視されたリモートアクセスの制限。また、MachineBから「ログアウト」すると、2つの「xxx.xxx.xxx.xxxへの接続が閉じられました」と表示されます。メッセージ。

1
Mcl

いくつかのジャンパーが必要だということです:)

最近、私はジャンパー1ジャンパー2と私の最終的なマシンでこの問題に遭遇しました、私のソル

ローカルスクリプト：

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

次に、最初のジャンパー（ルーター）に、Y00.shという名前のスクリプトを配置しました。

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

これらをIPとパスワードに置き換えることができます。

1
Z-Y00

ProxyCommandは、両方のシステムでシェルアクセスを許可する場合のクリーンなソリューションです。セキュリティを向上させるために、リモートユーザーにブローカー（B）を介して内部マシン（A）にアクセスできるようにしたかったのですが、ユーザーにシェルBへのアクセスを許可しませんでした。これは働いた：

ログインシェルを交換する

ブローカーのchshのログインシェルを（extuserを使用して）次のスクリプト（ファイルに保存）に置き換えます。

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

パスワードログインがリモートユーザーのextuser @ Bおよびextuser @ Bのinternaluser @ Aに設定されていない場合、次のコマンドを実行すると、リモートユーザーが直接Aに移動します。

ssh extuser@B

Tip：カスタムログインシェルに変更する前に、extuser @ Bに必要なパスワードなしのログインauthorized_keysセットアップを作成します。変更後、このアカウントはシェルを介してだれもアクセスできないため、sudoer @ Bのみが直接authorized_keysファイルを編集してファイルを変更できます。

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

最後の行は、Bからのログインバナーの表示を抑制することであるため、リモートユーザーはAに透過的にアクセスできます。

1
Sunthar