私は、ガイドに従うだけでなく、人々が尋ねてきたときに適切な対応を勧めることができるように、これを学ぼうとしています (尋ねてくる人はいます)。私が書き留めたものは次のとおりです。
まず、次のようなコマンドで両方のキーを生成します。
ssh-keygen -b 2048 -t rsa -C comment -f ~/.ssh/id_rsa
次に、キーの公開部分をauthorized_keys2ファイルにプッシュします。
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys2
(そしてそれを 600 または同様の値に変更します)
そして、秘密鍵 (id_rsa) をコンピューターにダウンロードし、それを Putty に入力して読み取って認証します。
SSH へのパスワードなしログイン用にこの公開/秘密キー認証を設定する手順は正しいですか?
答え1
説明されている手順は機能しますが、問題があります。ターゲット (リモート) コンピューターでキー ペアを生成し、秘密キー ファイルをローカル システムにダウンロードしています。ここでは、見落としてはならないセキュリティ上の問題があります。
- リモコンがすでに侵害されている場合は、誰かがパスフレーズを入手した可能性があります。
- 将来リモート システムが侵害された場合、攻撃者は秘密鍵ファイルにアクセスできるようになります (また、オフラインのブルート フォース攻撃を使用してそれを復号化することもできます)。
パスワード認証に固有の問題のいくつかを解決するために ssh キー ペアを使用している (解決しようとしている) ため、通常は次のようにします。
ローカル システムでキー ペアを生成します。理想的には、秘密キーは (a) 共有ファイル システム (NFS ホーム ディレクトリなど) に保存されず、(b) リモート ログインを許可するコンピューターに保存されません。
公開鍵を広く公開します。私は公開鍵を Web サイトに保存して、必要なときにいつでも取得できるようにしています。
authorized_keys接続先のシステム上の適切なファイルに公開鍵を配置します。
特に心配な場合は、秘密鍵をサムドライブに保存し、そのドライブは実行中の に鍵をロードするためだけに使用できますssh-agent。この時点で、実際の鍵ファイルはもう必要ありません。
答え2
クライアント システムでキーを生成する方がよい場合があります。authorized_keys ファイルのサイズが大きくなる可能性がありますが、侵害されたシステムを無効にする方が簡単です。サーバーの秘密キーを移行する場合は、キーを再生成してすべてのクライアント システムに移行する必要があります。各クライアントには独自のキーが必要です。
Putty はputtygenキーを生成するために を使用します。puttygenまた、クライアント システムに貼り付けるための正しい形式の公開キーも提供します。ログイン アクセスに使用する場合は、パスフレーズでキーを保護するのが最適です。 Pageantまたは、ssh-agent保護されていないキーをメモリに保持して、接続ごとにパスフレーズを再入力する必要がないようにすることもできます。
キーを 1 つ追加して保護を設定したら、権限をリセットせずにキーを追加できます。通常、次のような名前のシステムから公開キーをアップロードします (example.pub例はキーが属するシステムの名前)。
authorized_keys多くの実装では、キー ファイルとして を使用するようになりました。このファイルを使用すると、キーを受け入れるシステムを制限したり、コマンドを強制的に実行したり、アクセスを制限したりすることができます。man詳細については、ページを参照してください。
場合によっては、クライアント システムに複数のキーがあると便利なことがあります。これは、パスワードのないキーで実行されるバッチ プロセスをサポートするために行うことができます。
答え3
それは良さそうです。多くの人は逆の方向（ローカルでキーを生成し、それを.pubサーバーにプッシュする）で実行しますが、どちらでも機能します。