web-dev-qa-db-ja.com

sshキーはid_rsaという名前にする必要がありますか？

キー付き認証でビルドサーバーを作成するときに、この問題に何度か遭遇しました。

他の誰かがこれを経験したことがあるのだろうかと思いました。現在のユーザー用に、異なるマシンに接続できるキーがいくつかあります。 machine1とmachine2と言います。公開鍵をそれぞれのauthorized_keysファイルに貼り付けました。最初のキーにid_rsaという名前を付け、2番目のキーベンダーに名前を付けました。

ベンダーに接続しようとすると、冗長なssh接続で次の出力が得られます

debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/bozo/.ssh/.ssh/identity
debug1: Trying private key: /home/bozo/.ssh/.ssh/id_rsa
debug1: Trying private key: /home/bozo/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

上記のように、id_rsaキーのみを提供します。これは正しいです？もしそうなら、なぜですか？より多くのキーを提供するにはどうすればよいですか？私は家にいるのであまり問題なく複数のキーを持っているので、断続的に見られる問題であることを知っています。

また、pubキーとprivateキーがクライアントとサーバーとどのように相互作用するかについての概要も評価したいと思います。私はかなりまともなアイデアを持っていると思ったが、どうやら何かが欠けているようだ。

お願いします。

sshopenssh
129
myusuf3

デフォルトでは、sshはid_dsaおよびid_rsaファイルを検索します。キーにこのような名前を付ける必要はありません。mykeyという名前を付けることも、別のディレクトリに配置することもできます。ただし、これらのいずれかを行う場合は、次のようにsshコマンドで明示的にキーを参照する必要があります。

ssh user@server -i /path/to/mykey

コマンドが-iを受け入れない場合、たとえばsshfs、IdentityFileオプションを使用します。

sshfs -o IdentityFile=/path/to/mykey user@Host:/path/on/remote /mountpoint

使い方

キーを生成すると、2つのファイルid_rsa（プライベートキー）とid_rsa.pub（公開キー）が取得されます。名前が示すように、秘密鍵は秘密にしておく必要があり、公開鍵は一般に公開できます。

公開鍵認証は、公開鍵と秘密鍵で機能します。クライアントとサーバーの両方に独自のキーがあります。 openssh-serverをインストールすると、サーバーの公開鍵と秘密鍵が自動的に生成されます。クライアントの場合は、自分でそれを行う必要があります。

（クライアント）がサーバーに接続すると、公開鍵が交換されます。サーバーを受け取り、サーバーを受け取ります。サーバーの公開鍵を最初に受け取るとき、それを受け入れるように求められます。この公開鍵が時間の経過とともに変化する場合、クライアントとサーバー間のトラフィックを傍受する可能性のあるMITM（中間者）攻撃が行われているため、警告が表示されます。

サーバーは、ユーザーが接続を許可されているか（/etc/ssh/sshd_configで定義されているか）、および公開キーが~/.ssh/authorized_keysファイルにリストされているかどうかを確認します。公開鍵が拒否される理由として考えられるもの：

  • /etc/ssh/sshd_config：
    • AllowUsersまたはAllowGroupsが指定されているが、サーバーユーザーがグループまたはユーザーリストにリストされていない（デフォルトは定義されておらず、ユーザーまたはグループのログインに制限はありません）。
    • DenyUsersまたはDenyGroupsが指定されており、ユーザーまたはグループのリストに含まれています。
    • ルートとしてログインしようとしていますが、PermitRootLoginはNo（デフォルトyes）に設定されています。
    • PubkeyAuthenticationはNoに設定されます（デフォルトはyes）。
    • AuthorizedKeysFileは別の場所に設定され、公開鍵はそのファイルに追加されません（デフォルト.ssh/authorized_keys、ホームディレクトリに相対的）
  • ~/.ssh/authorized_keys：このファイルに公開鍵は追加されません（このファイルはrootユーザーとして読み取られることに注意してください）

複数のキーを使用する

複数のキーを使用することは珍しくありません。 ssh user@Host -i /path/to/identity_fileを実行する代わりに、構成ファイル~/.ssh/configを使用できます。

一般的な設定は、IdentityFile（キー）とポートです。次の設定では、ssh youruser@yourhostで接続する場合にのみ「id_dsa」と「bender」をチェックします。

Host yourhost
   IdentityFile ~/.ssh/id_dsa
   IdentityFile ~/.ssh/bender

Host yourhostを省略すると、設定はすべてのSSH接続に適用されます。このホスト一致には、User youruser、Port 2222などの他のオプションも指定できます。これにより、ssh yourhostの代わりにssh -p2222 youruser@yourhost -i ~/.ssh/id_dsa -i ~/.ssh/benderの短縮形で接続できます。

156
Lekensteyn

私のお気に入りの方法では、秘密鍵を自動的に選択できます

IdentityFile ~/.ssh/%l_%r@%h_id_rsa

SSHは％lをローカルマシン名に、％rをリモートユーザー名に、％hをリモートホストに置き換えます。したがって、fooというマシンからユーザーとしてbarに接続する場合、次のコマンドを実行します。

ssh bar

Sshは自動的に次を使用します。

~/.ssh/foo_user@bar_id_rsa

ローカルホストも格納されるため、これにより、NFS（マシンごとに異なるキー！）を介して共有されるホームディレクトリが可能になります。

40
Viperfang

多くのキーを指定するのに時間がかかるというStevenRooseのコメントを考慮して、たまたま多くのキーで遊んでいるので、個人的な解決策を提案したいと思います。

その時点で使用するキーへのシンボリックリンクを作成します。これは、作業中のプロジェクトに応じてめったに変更されないため、満足しています。

ここで、virtualboxの下で実行されているマシンのキーにリンクしています。

$ cd .ssh/
$ ln -s adam_vbox-id_rsa.pub id_rsa.pub
$ ln -s adam_vbox-id_rsa id_rsa

$ ls -l
total 12
-rw------- 1 adam adam 1675 2013-10-04 02:04 adam_vbox-id_rsa
-rw-r--r-- 1 adam adam  396 2013-10-04 02:04 adam_vbox-id_rsa.pub
lrwxrwxrwx 1 adam adam   16 2013-10-04 02:17 id_rsa -> adam_vbox-id_rsa
lrwxrwxrwx 1 adam adam   20 2013-10-04 02:17 id_rsa.pub -> adam_vbox-id_rsa.pub
-rw-r--r-- 1 adam adam 3094 2013-10-04 02:09 known_hosts

また、手動でlnコマンドを再度入力することなく、別のセットに切り替えるための非常に簡単なスクリプトを追加することもできます。

繰り返しますが、これは2つのキーだけの解決策ではありませんが、より多くのキーについては実行可能かもしれません。

1
ajhcasual