あり非常によく似た質問と答えた場合は、この質問への答えであったかもしれないということは。残念ながら、「問題は私が思っていたものではなかったので、私が尋ねた質問に答える必要はない」の場合です。

セットアップ

1. サーバbastion.ec2はからのSSH接続を受け入れる私のワークステーションを経由しssh -i mykey.pem myname@bastion.ec2
2. サーバーservice1.ec2は、bastion.ec2からのみ ssh接続を受け入れます。ssh -i sharedkey.pem shareduser@service1.ec2

要求事項

1. 両方のキーは私のワークステーションにのみあるので、キーをコピーせずに2番目のコマンドを実際に実行することはできません
2. セキュリティ上の理由から、sshキーをbastion.ec2にコピーするのではなく、ssh-agent転送を使用したいと思います。

ソリューション

ここが出てきます。2番目の接続用に別のキーを転送するにはどうすればよいですか？

shareduserにmykey.pubが含まれている場合、~/.ssh/authorized_keysこれは機能します。

ssh -i mykey.pem myname@bastion.ec2 ssh shareduser@service1.ec2

ただし、すべてのユーザーが自分の公開鍵をすべてのサーバーに配置する必要はありません。

ステップ1

ローカルエージェントの準備ができていることを確認してください

キーパスを指定したり、パスワードの入力を求められたりせずに要塞サーバーに sshでログインできるからといって、sshエージェントが実行中でキーを保持しているとは限りません。いくつかの最近のOS（例：OSX）はこれを処理します。

ローカルマシン

$ ssh-add -L
ssh-rsa ObahfCbvagGbLbhSbeHfvatEBG13== ~/.ssh/mykey.pem
ssh-rsa LbhNerWhfgJnnlGbbPyrireEBG13== ~/.ssh/sharedkey.pem

^図1

つまり、エージェントが実行中であり、キーを持っています。

$ ssh-add -L
The agent has no identities.

^図2

つまり、エージェントにキーを追加していません。それを修正します：

ssh-add ~/.ssh/mykey.pem ~/.ssh/sharedkey.pem

^図3

ステップ2

リモートエージェントの準備ができていることを確認してください

あなたの要塞サーバへのSSHからチェックを繰り返し、図1＆図2。ただし、発生する可能性が高いエラーは次のとおりです。

$ ssh-add -L
Could not open a connection to your authentication agent.

^図4

SSHクライアントが認証エージェント接続を転送していない可能性があります。

これは-Aフラグで強制できます（サーバーのsshd構成で許可されている限り、これがデフォルトです）。

$ ssh -A bastion.ec2

^図5

ステップ3

正しいキーを使用していることを確認してください

エージェントにキーを追加した場合、エージェントは転送中であり、リモートエージェントはローカルキーをリストします。接続が確立されない理由は2つだけあります。正しいキーを使用していないか、正しいユーザー名を使用していないかのどちらかです。

対応する公開鍵を秘密鍵に出力します。

$ cd
$ cd .ssh
$ ssh-keygen -y -f mykey.pem
ssh-rsa ObahfCbvagGbLbhSbeHfvatEBG13
$ ssh-keygen -y -f sharedkey.pem
ssh-rsa LbhNerWhfgJnnlGbbPyrireEBG13

^図6

これらは、最後から最後ssh-add -Lまで見たものと同じでなければなりません==。

ここで、何らかの方法で、接続に失敗したボックスに入って、接続$HOME/.ssh/authorized_keysしようとしているユーザーのファイルの内容を確認する必要があります。上記のコマンドで出力した公開鍵が、そのファイル内の1行にあることを確認する必要があります。sharedkey.pubBro 2キューブがあなたに電子メールを送ったのが正しいとは信じられません。確認！これには、そのユーザーとしてSSHでログインできる他の誰かに、authorized_keysファイルを取得するか、rootアクセスを取得する必要がある場合があります。ここまで来ても問題が解決しない場合は、近道はありません。

ステップ4

簡単にする

上記の手順がうまくいったことを願っています。次に、このワークステーションを使用している限り、この頭痛の種を解消しましょう。

ローカルSSHクライアントを構成する

Host *
    # A lot of people put an IdentityFile line in this Host * section.
    # Don't do that unless you will use only 1 key everywhere forever.
    #IdentityFile id_rsa

Host bastion.ec2
    # You want to make sure you always forward your agent to this host.
    # But don't forward to untrusted hosts. So don't put it in Host *
    ForwardAgent yes
    # Go a head and put the IP here in case DNS ever fails you.
    # Comment it out if you want. Having it recorded is a good backup.
    HostName 172.31.0.1
    # You don't want to create a proxy loop later, so be explicit here.
    ProxyCommand none
    # SSH should try using all keys in your .ssh folder, but if you
    # know you want this key, being explicit speeds authentication.
    IdentityFile ~/.ssh/mykey.pem

# Connect effortlessly by hostname or IP address
# This assumes that your internal DNS uses the fake TLD ec2
# This assumes that 172.31.0.0 is your C-Class subnet
Host *.ec2 172.31.*
    # This command says proxy all ssh connections through bastion as if
    # you had done an ssh -A
    ProxyCommand ssh -W %h:%p bastion.ec2
    ForwardAgent yes
    # These next lines are documentation you leave as a love letter to
    # your future self when all else fails or you have to help a
    # coworker and decide to look at your own config.
    # ssh-add ~/.ssh/*.pem
    # ssh -At bastion.ecs ssh admin@172.31.18.19

^図7

あなたがfig.7から他に何も取らなければ、それはProxyCommand＆の適切な使用であるべきForwardAgentです。

.bash_profileに自動入力

ssh-addマシンにログインするたびに手動で行う必要はありません。~/.bash_profileログインするたびに実行されるスクリプトです**。イチジクからの線を入れてください。そこに3つあり、常にエージェントの準備ができている必要があります。

** .bashrcこれを、新しい[インタラクティブ]端末ごとに実行されると混同しないでください。すべてのターミナルセッションを閉じても、エージェントは実行を続けます。キーをリロードする必要はありません

.bash_profileを使用する代わり

OSX / macOS Launch Agentを追加する要点も作成しました。ssh-agent起動時にその方法を使用できます。インストールは非常に簡単です。

curl -sSL https://gist.github.com/RichardBronosky/429a8fff2687a16959294bcee336dd2a/raw/install.sh | bash

ここが出てきます。2番目の接続用に別のキーを転送するにはどうすればよいですか？

鍵は転送しません。エージェントを転送すると、最初のジャンプで認証に使用するよりも完全に独立したキーを持つことができます。を使用してエージェントのキーを確認しますssh-add -L。

しかし、さらに良いのは、を介して接続を実行ProxyCommand ssh -W %h:%p myname@bastion.ec2することです。これにより、エージェント、ヒープまたはコマンドラインオプションを転送する必要がなくなり、直接のホストから認証を受ける必要がなくなります。

あなたは単にそれをあなたの設定に置くことができます（を見てくださいman ssh_config）。