私は有効な構成をセットアップして2台目のマシンとの接続を確立し、別のマシンを通過させ、id_rsa(パスワードを要求する)を使用して3台目のマシンに接続するのに苦労してきました。
私は別のフォーラムでこの質問をしましたが、非常に役立つと思われる答えを受け取っていません。
より詳しく説明すると、問題は次のようになります。
Local machine: user1@localhost
Intermediary machine: user1@inter
Remote target: user2@final
Pseudo-ttyを使用して接続全体を行うことができます。
ssh -t inter ssh user2@final
(これにより、マシン「inter」にあるid_rsaファイルのパスワードが要求されます)
ただし、処理を高速化するために、.ssh/configファイルを設定して、次のコマンドを使用してマシン "final"に簡単に接続できるようにします。
ssh final
私がこれまでに得たもの-これは機能しません-は、私の.ssh/configファイルにあります:
Host inter
User user1
HostName inter.com
IdentityFile ~/.ssh/id_rsa
Host final
User user2
HostName final.com
IdentityFile ~/.ssh/id_rsa_2
ProxyCommand ssh inter nc %h %p
Id_rsaファイルはミドルマシンへの接続に使用され(これにはパスワードの入力は不要です)、id_rsa_2ファイルはマシン "final"への接続に使用されます(これはパスワードを要求します)。
いくつかのLocalForward
フィールドやRemoteForward
フィールドを混同し、id_rsaファイルを1番目と2番目のマシンの両方に配置しようとしましたが、何も設定しなければ成功しなかったようです。
PS:私がいくつかの助けを得ようとしたスレッド:
http://www.linuxquestions.org/questions/linux-general-1/proxycommand-on-ssh-config-file-4175433750/
認証フローを保持したい場合
local -- authenticate --> inter -- authenticate (ask password) --> final
これは.ssh/config proxyhostでは実行できません。
必要なのはbashシェルエイリアスです(bashを使用していると思います)。
~/.bashrc
に、次の行を追加します
alias ssh-final='ssh -t inter ssh [email protected]'
コマンドプロンプトで、次のように入力します
ssh-final
~/.ssh/config
のfinal
セクションは使用されません。
ssh -t inter ssh [email protected]
は次のように表示できます
local# ssh inter
inter# ssh [email protected]
local
はinter
とのみ「対話」しています。 local
とfinal
の間に直接または間接的なssh接続はありません。 local
はssh [email protected]
の出力を表示しているだけです。
Host inter
User user1
HostName inter.example.com
Host final
User user2
Hostname <final.com / final IP Address>
Port 22
ForwardAgent yes
ProxyCommand ssh inter nc %h %p
local~/.ssh/id_ras.pub
をコピー
/home/user1/.ssh/authorized_keys in `inter`
/home/user2/.ssh/authorized_keys in `final`
sshトンネリング
ProxyCommand
の詳細に入る前に、次の例を見てみましょう
ステップ1、ターミナルウィンドウ1
local# ssh inter -L 2000:final.com:22
ステップ2、ターミナルウィンドウ2
local# ssh localhost -p 2000
端末1では、ローカルポート2000とfinal.comポート22の間にトンネルが設定されます。ローカルポート2000に送信されたものはすべて、final.comポート22に転送され、その逆も同様です。
端末2では、sshはローカルポート2000に接続しますが、実際にはfinal.comポート22(sshd)と通信しています。
トンネリングでは、ステップ2のローカルsshクライアントがfinal.com sshdに直接接続されます。
ローカルポート2000の「出力」は、「生の」sshデーモントラフィックです。
このようなトンネルの一般的な使用法は、内部Webサーバーまたは電子メールサーバーへのアクセスです。以下はウェブサーバーの例です
local# ssh inter -L 2000:final.com:80
ブラウザで次のURLを使用します
http://localhost:2000
トンネルの2つのエンドポイントは、ローカルポート2000とfinal.comポート80です。
トンネルのエンドポイントに出入りするトラフィックは「現状のまま」です。それを「生の」トラフィックと呼びましょう。
ProxyCommand
Host final
User user2
Hostname <final.com / final IP Address>
Port 22
ForwardAgent yes
ProxyCommand ssh inter nc %h %p
ProxyCommand
をさらに一歩進めましょう。ローカルポートを作成して接続する手順をスキップします。
Sshクライアントは、ProxyCommand
の背後にあるコマンドを実行し、そのコマンドの出力を「生の」トラフィックとして扱います。ローカルエンドポイントを保持し、それからssh接続を開始します。
一方が機能しない理由
次のコマンド
ssh inter nc final.com 22
基本的には、(1)inter
に接続し、次に(2)inter
でコマンドnc final.com 22
を実行することを意味します。
nc - arbitrary TCP and UDP connections and listens
したがって、nc final.com 22
はfinal.comのポート22に接続し、すべての着信トラフィックをstdoutに出力して、すべてのstdinを反対側に送信します。これは、nc stdin/outとfinal.comポート22の間の「トンネル」です。
nc
はsshセッション内で実行されるため、そのすべてのstdoutは「生の」トラフィックとしてsshクライアントに戻されます。また、sshクライアントはnc stdinにトラフィックを渡すことができ、最終的にfinal.comポート22に到達します。
上記の「トンネル」を通じて、ローカルのsshクライアントはfinal.com
を使用してsshセッションを直接開始します。
次のコマンド
ssh -t inter ssh [email protected]
ProxyCommand
は、sshデーモンからの「生の」トラフィックではないため、機能しません。 ssh clientの標準出力です。クライアントとクライアントの会話はビジネスを意味しません。
Host inter
User user1
HostName inter.com
IdentityFile ~/.ssh/id_rsa
Host final
User user2
HostName final.com
IdentityFile ~/.ssh/id_rsa_2
ProxyCommand ssh inter nc %h %p
local~/.ssh/id_ras.pub
をコピー
/home/user1/.ssh/authorized_keys in `inter`
local~/.ssh/id_ras_2.pub
をコピー
/home/user2/.ssh/authorized_keys in `final`
上記の両方により、次の使用法が可能になります
local# ssh final
local# ssh -v final
これは、sshの問題を特定するのに役立ちます。
ProxcyCommand
はnc
でinter
を実行しています。 nc
が実際にinter
で使用できるかどうかを確認します。
local# ssh inter
inter# nc final.com 22
inter
とfinal
に異なるキーを使用する場合、次のファイルがローカルマシンに存在する必要があります
local# ls ~/.ssh
id_rsa id_rsa_2 id_rsa.pub id_rsa_2.pub
すでにinter
にsshできるので、final
のキー設定を確認してください。ローカルマシンから
local# ssh -t inter ssh user2@final
final# cat .ssh/authorized_keys
そこにid_rsa_2.pub
のコンテンツが表示されます。
実際にエラーが表示されたり、ssh -vステートメントが表示されていなかったので、どこでハングアップしているかがわかります。
おい、あなたはそれをほぼ正しく持っています---最善かつ最も安全な方法は、ローカルマシンにbothキーを持つことです。次に、中間ステップでキーを残さずに、ssh-agent転送を使用して接続します。ログオンごとに1回だけキーパスフレーズを入力する必要があるという利点もあります。
Ubuntu(ローカルマシン上)のような最新のユーザーフレンドリーなOSを使用している場合、これは*メッセージング*なしで問題なく動作するはずです。 IDファイルを意図的に省略したので、必要ありません。
設定ファイルは次のようになります。
Host inter
User user1
ForwardAgent yes
HostName inter.com
Host final
ForwardAgent yes
User user2
HostName final.com
ProxyCommand ssh inter nc %h %p
そうでない場合は、以下の手順を実行して、ssh-agentが実行されていることを確認します。
'ssh-add -l' (lower case L) will list your private keys if any are loaded, or will be blank, or will say can’t connect to ssh-agent, if so, start ssh-agent.
'eval `ssh-agent`' (those are backticks) starts ssh agent
'ssh-add' will add your key… you can add a path argument if you have a key in a non-default area. At this point you will enter your passphrase.
これがどのように機能するかを説明する素敵なガイドがあります こちら