☰

ProxyCommand と netcat モードを使用する場合、ssh で設定からホスト名を解決する

tag-icon • tag-icon ssh proxy
ProxyCommand と netcat モードを使用する場合、ssh で設定からホスト名を解決する

SSH 接続をバウンスするための汎用オプションをいくつか設定しようとしています。以下は私の~/.ssh/configファイルです (省略形):

Host *%via
  ProxyCommand ssh gateway -W $(echo %h | cut -d%% -f1) %p

Host gateway
  HostName gateway.example.com
  User username
  ForwardAgent yes
  IdentityFile keypathg

Host target
  User username
  HostName target.example.com
  IdentityFile keypatht

*%viaエイリアスを使用するとHost、次のようになります。

% ssh -vvv target%via
OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /Users/myuser/.ssh/config
debug1: /Users/myuser/.ssh/config line 5: Applying options for *
debug1: /Users/myuser/.ssh/config line 12: Applying options for *%via
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/Users/myuser/.ssh/tmp/target%via_22_myuser" does not exist
debug2: ssh_connect: needpriv 0
debug1: Executing proxy command: exec ssh -A gateway -W $(echo target%via | cut -d% -f1):22
debug1: permanently_drop_suid: 501
debug1: identity file /Users/myuser/.ssh/id_rsa type -1
debug1: identity file /Users/myuser/.ssh/id_rsa-cert type -1
debug1: identity file /Users/myuser/.ssh/id_dsa type -1
debug1: identity file /Users/myuser/.ssh/id_dsa-cert type -1
ssh_exchange_identification: Connection closed by remote host

しかし、私が

% ssh target.example.com%via

ターゲット サーバーにアクセスしましたが、間違ったユーザーとしてアクセスし、公開鍵認証も行われませんでした。

私考えるこの時点での私の質問は、このバウンス方法は、使用時にForwardAgent、SSH 構成/環境全体を通過するのか、それともキーだけを通過するのかということです。キーだけの場合、前者は何らかの方法で利用できますか?

私の ssh バージョンは 5.9v1、ゲートウェイは 5.9v1、ターゲットは 5.3p1 です。5.4-Wで導入されたと思いますが、これは最終ボックスでは問題にならないのでしょうか? 古いバージョンを使用してncも違いはないようです。

行内の各ボックスに手動で ssh できることを確認しました。これを行うと、ホスト名のエイリアス情報が渡されないことがわかります。ゲートウェイでは渡せませんが、ssh targetは渡せますssh target.example.com。これは、公開鍵認証で機能します。ゲートウェイとターゲットは偶然にも同じユーザー名を持っているため、構成がプッシュされていない場合はこれが機能します。

または同様の構成でこの情報をプッシュできない場合ForwardAgent、この情報を含む .ssh/config をゲートウェイに保持して回避する最も合理的な方法は何ですか?

答え1

わあ、この質問をしてくれてありがとう。SSH を完全に活用している人を目にするのは珍しいと思いますが、この質問はいくつかの領域に当てはまります。

これは問題ではありませんProxyCommand。 はProxyCommand、単にローカルの SSH クライアントに、リモート クライアントと通信する前に準備として何かを行うように指示するだけです。はい、この例では別の SSH セッションと通信しますが、そのセッションは、 とともに、-W単に入力を取得して別のマシンに転送します。準備の SSH セッションは完全に独立していると考えることができます。避けられない車のアナロジー: A 地点から B 地点までフェリーに乗らなければならなかったかどうかに関係なく、車は同じ車です。

これは問題ではありませんForwardAgent。 ForwardAgentローカル クライアントが、リモート セッションの環境内でローカル キーを使用できるようにする機能を提供しているかどうか。リモート セッションの確立をまだ完了していません。

これはフォーマットの問題です.ssh/config。debug1 の 2 行目と 3 行目に注意してください。これらは、 から適用されているホスト スタンザをリストします.ssh/config。 は動作しますが、ユーザー名とキーが間違っていることに注意してください$ ssh target.example.com%via。 のスタンザがHost target読み込まれていません (これにより、正しいユーザー名とキーファイルが提供されます)。どのスタンザが使用されていますか? *および*%via。

これらのオプションを渡すにはどうすればよいのでしょうか? 興味深いことに、ワイルドカードは長さ 0 の文字列と一致します。 、、およびとHost target*一致します。targettarget%viatarget.example.comtarget.example.com%via

それで、マシン.ssh/configにを設定するgatewayと役立つかどうかという疑問が生じます。いいえ、役に立ちません。読み取られることはありません。すべてはローカル マシンから実行されます。

私が説明したことはすべて、なぜ$ ssh target.example.com%via機能しないのかという答えにすぎません。

あなたは を好みます$ ssh target%via。当然です、より便利です。短縮形が失敗するのは、ホスト名としてtargetが見つからないため、解決されないからです。 はなぜ ssh が を吐き出さないのでしょうかssh: Could not resolve hostname target: Name or service not known? はProxyCommand既に正常に確立されているからです。ssh 接続の要素は構築されていますが、ホスト名の失敗は予期しない場所で発生しており、そのためより一般的なメッセージで失敗しています。これについてバグレポートを提出して、デバッグ情報を改善できる場所を特定できるようにします。

最終解説:

このHost *%via構文は気に入っています。簡潔でありながら柔軟性があります。以前見たことがありますHost *+*が、これは の最初と最後の部分の両方を使用して、%h(ost)どこに行くかを決定します。ただし、それを理解するにはもう少し努力が必要です。リンク:http://wiki.gentoo.org/wiki/SSH_jump_host

関連情報