トンネルを介したid_rsaを使用したssh構成ファイルのセットアップ


17

有効な構成をセットアップして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ファイルを設定して、次のコマンドを使用して「最終」マシンに簡単に接続できるようにします。

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ファイルを最初のマシンと2番目のマシンの両方に配置しようとしましたが、設定がまったくなく成功するようには見えませんでした。

PS:私が助けを得ようとしたスレッド:

http://www.linuxquestions.org/questions/linux-general-1/proxycommand-on-ssh-config-file-4175433750/

回答:


21

方法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とはfinallocalの出力を表示しているだけです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実行されているncinterncで実際に利用できるかどうかを確認しinterます。

local# ssh inter
inter# nc final.com 22

RSAキーが正しくセットアップされていることを確認してください

異なるキーがために使用されるようにしている場合interfinal、次のファイルがローカルマシンに存在している必要があります

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です。
ルーベンス

設定ファイルは、投稿したものでも動作するはずです。checkingステップを試してみてください。何か不足している/間違っている必要があります。
ジョンシウ

1
ssh -t、あなたのssh to finalはから開始されますinter。これはlocal# ssh interthen とほぼ同じinter# ssh finalです。認証が間にあるinterfinal。proxy / ncを使用すると、ssh to finalはローカルマシンからトンネルを介してに開始されますfinal。認証が間にあるlocalfinal
ジョンシウ

@Rubensはあなたのコメントに基づいて、あなたがまだinterssh-keyを使ってで認証していると勘違いしていると思いますfinal。〜/ .ssh / id_rsa_2にコピーid_rsa_2してみてlocal(ローカルid_rsaを上書きしないでください)、問題はなくなった可能性があります。
ジョンシウ

2
ssh2がnc組み込まれていることに注意してください。したがって、代わりにをProxyCommand ssh gateway nc %h %p記述しProxyCommand ssh inter -W %h:%pます。
user123444555621 14

2

実際にエラーがリストされたり、ssh -vステートメントが表示されなかったため、どこでハングしているのかわかります。

ねえ、あなたはそれをほぼ正しく持っている---最良かつ最も安全な方法は、ローカルマシン上に両方のキーを持っていることです。次に、中間ステップでキーを残すのではなく、ssh-agent転送を使用して接続します。また、ログオンごとに1回だけキーパスフレーズを入力する必要があるという利点もあります。

(ローカルマシン上で)ubuntuのような現代的で使いやすいOSを使用している場合、これは* massaging *なしで問題なく動作するはずです。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.

これがどのように機能するかを説明した素晴らしいガイドがここにあります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.