web-dev-qa-db-ja.com

トンネル経由のid_rsaを使用したSSH構成ファイルの設定

私は有効な構成をセットアップして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/

linuxsshssh-tunnelrsa
17
Rubens

方法1（インターでssh-keyを使用）

認証フローを保持したい場合

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セクションは使用されません。

接続の詳細（1）

ssh -t inter ssh [email protected]は次のように表示できます

local# ssh inter
inter# ssh [email protected]

localはinterとのみ「対話」しています。 localとfinalの間に直接または間接的なssh接続はありません。 localはssh [email protected]の出力を表示しているだけです。

方法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

local~/.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サーバーまたは電子メールサーバーへのアクセスです。以下はウェブサーバーの例です

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の標準出力です。クライアントとクライアントの会話はビジネスを意味しません。

異なる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

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の問題を特定するのに役立ちます。

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のコンテンツが表示されます。

21
John Siu

実際にエラーが表示されたり、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.

これがどのように機能するかを説明する素敵なガイドがあります こちら

2
MattPark