方法1(インターでssh-keyを使用)
認証フローを保持する場合
local -- authenticate --> inter -- authenticate (ask password) --> final
これは、.ssh / configプロキシホストでは実行できません。
必要なのはbashシェルエイリアスです(bashを使用していることを願っています)。
では~/.bashrc
、次の行を追加します。
alias ssh-final='ssh -t inter ssh user2@final.com'
コマンドプロンプトで、次のように入力します
ssh-final
final
セクション~/.ssh/config
は使用されません。
接続の詳細(1)
ssh -t inter ssh user2@final.com
次のように表示することができます
local# ssh inter
inter# ssh user2@final.com
local
に「話している」だけinter
です。間に直接または間接的なSSH接続がありませんlocal
とはfinal
。local
の出力を表示しているだけですssh user2@final.com
。
方法2(ローカルでssh-keyを使用)
同じssh-keyを使用した認証
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
ローカル ~/.ssh/id_ras.pub
にコピー
/home/user1/.ssh/authorized_keys in `inter`
/home/user2/.ssh/authorized_keys in `final`
接続の詳細(2)
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サーバーまたは電子メールサーバーにアクセスすることです。以下は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
実行して、commandを実行することを意味しnc final.com 22
ます。
nc - arbitrary TCP and UDP connections and listens
したがってnc final.com 22
、final.comポート22に接続し、すべての着信トラフィックを標準出力に出力し、すべての標準入力を反対側に送信します。これは、nc stdin / outとfinal.comポート22の間の「トンネル」です。
以来nc
、SSHセッション内で走っている、すべての標準出力は「生」トラフィックとして、バックsshクライアントに渡されます。また、sshクライアントは、nc stdinにトラフィックを渡すことができます。ncstdinはfinal.comポート22に到達します。
上記の「トンネル」を通じて、ローカルsshクライアントはsshセッションをfinal.com
直接開始します。
次のコマンド
ssh -t inter ssh user2@final.com
ProxyCommand
アウトはsshデーモンからの「生の」トラフィックではないため、動作しません。sshクライアントの標準出力です。クライアントとクライアントとの会話はビジネスを意味しません。
異なるssh-keyによる認証(OPオリジナル設定)
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
ローカル ~/.ssh/id_ras.pub
にコピー
/home/user1/.ssh/authorized_keys in `inter`
ローカル ~/.ssh/id_ras_2.pub
にコピー
/home/user2/.ssh/authorized_keys in `final`
上記の両方により、次の使用が可能になります
local# ssh final
追加の確認
詳細を使用する
local# ssh -v final
これは、sshの問題を特定するのに役立つはずです。
ncを確認
ProxcyCommand
実行されているnc
のinter
。nc
で実際に利用できるかどうかを確認しinter
ます。
local# ssh inter
inter# nc final.com 22
RSAキーが正しくセットアップされていることを確認してください
異なるキーがために使用されるようにしている場合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 -t
が、私がしたいのはssh -t
、の設定のみを使用して使用することで得られる動作を正確にシミュレートすること.ssh/config
です。