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

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

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

1. 別の大学のマシンにログインします（マシンBと言います）

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

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

もっと速くする方法はありますか？1つのsshコマンドのみを使用します。

はい、ProxyCommandSSH config で使用します。

ホームディレクトリに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を使用し、ncそこからターゲットに単純な 'netcat'（）を直接設定することにより、これは基本的に、それらの間のブローカーから内部マシンに転送されるプレーンテキストです。-qオプションは、任意の出力（単に個人的な好み）を沈黙させるです。

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

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

一度にホップ

私が他の回答で提供した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を強制的に割り当てます

この欠点は、すべての構成、検証、および認証がマシンBで行われるようになったことです。これは、セキュリティ上の理由で私の状況では本当に好きではありません。私は自分のPC上のキーペアが好きで、自分のPCから最終的なターゲットマシンを認証および検証します。さらに、SSHにはインタラクティブシェルしか使用できないため、SCPやGUIファイルマネージャーのような他のツールを使用することはできません。

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

-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以降で使用できます。

使用してみてください

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

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

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

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

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

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

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

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

複数のジャンパーが必要だということです:)

最近、私はジャンパー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とパスワードに置き換えることができます。幸運を祈ります！