web-dev-qa-db-ja.com

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

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

% 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

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

think私の質問は、この時点で、ForwardAgentを利用するとき、このssh構成/環境全体、または単にキーを通過するときに、このバウンス方法を実行することです。キーだけの場合、前者は何らかの方法で利用できますか?

私のsshバージョンは5.9v1、ゲートウェイは5.9v1、ターゲットは5.3p1です。 -Wは5.4で導入されたと思いますが、最後のボックスでは問題になりませんか?古い学校を利用することはncも同じように見えます。

行の各ボックスに手動でsshできることを確認しました。そうすることは、ゲートウェイ上にあるときのように、ホスト名のエイリアス情報が渡されないことを示します。ssh targetはできませんが、ssh target.example.comはできます。これはpubkey authで動作します。ゲートウェイとターゲットが偶然同じユーザー名を持っているため、設定がプッシュされない場合にこれが機能します.

ForwardAgentまたは同様の構成でこの情報をプッシュできない場合、この情報を使用してゲートウェイで.ssh/configを維持し、それを回避する最も適切な方法は何ですか?

16

わあ、この質問をしてくれてありがとう。誰かがSSHを完全に悪用しているのを見かけるのは稀で、この質問はいくつかの分野に当てはまります。

これはProxyCommandの問題ではありません。 ProxyCommandは、ローカルsshクライアントに、リモートクライアントとの通信を試行する前に何か準備をするように指示するだけです。はい、私たちのインスタンスでは、別のsshセッションと通信しますが、そのセッションは_-W_を使用して、単に入力を受け取り、それを別のマシンに転送します。準備のsshセッションは完全に独立していると考えることができます。避けられない車の類推:ポイントAからポイントBまでフェリーに乗る必要があったかどうかに関係なく、あなたの車は同じ車です。

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

これは_.ssh/config_形式の問題です。 2番目と3番目のdebug1行に注意してください。 _.ssh/config_から適用されているHostスタンザをリストします。 _$ ssh target.example.com%via_は機能するが、ユーザー名とキーが間違っていることに注意してください。まあ、_Host target_のスタンザは読み取られていません(正しいユーザー名とキーファイルが提供されます)。どのスタンザが使用されていますか? _*_および_*%via_。

これらのオプションを渡す方法は?興味深いことに、ワイルドカードは長さ0の文字列と一致します。 _Host target*_は、target、_target%via_、_target.example.com_および_target.example.com%via_と一致します。

そして、あなたが質問をすると、gatewayマシンヘルプで_.ssh/config_を設定します。いいえ、そうではありません。それは決して読まれないでしょう。私たちのローカルマシンからすべてが起こっています。

私が説明したすべてのことは、_$ 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

14
Hefeweizen