SSH公開鍵を使用するリスク

私が持っている、サーバAとサーバB（バックアップ）、およびサーバAに誰かが破損した場合、私はこれは私がSSH公開鍵を使ってパスワードなしログインを設定している場合、サーバーBに侵入する潜在的に危険な可能性があり、不思議でしたか？

rsnapshotをセットアップしようとしています。

ありがとう

はい、これはパスワードなしのSSHキーの問題の1つです。サーバーBへの接続を許可する秘密鍵をサーバーAに保存する場合、サーバーAへのアクセスを取得することは、サーバーBへのアクセスを効果的に取得することになります（逆は当てはまりません-サーバーBへのアクセスを取得しても、その方向でパスワードなしのログインを許可するように設定されたSSHキーも持っていないと想定して、サーバーAの即時の侵害。

これを軽減するためにできることがいくつかあります。

• プロセスを完全に自動化する必要がない場合は、SSHキーにパスワードを追加します。（これはバックアップ用であるため、これはおそらく機能しません）
• 自分のアカウントで複数のマシンにパスワードなしでログインする場合は、物理的に入力するマシンごとにパスワード付きのキーを作成し、SSHエージェントを使用してキーをメモリに保存して使用することをお勧めします。エージェント転送を使用すると、各リモートホストでキーを作成しなくても、ホストからホストに「ホップ」できます。
• 自動化されたパスワードなしのSSHキーについては、キーが実行できるコマンドを制限することをお勧めします。あなたにはauthorized_keys、ファイル、あなたの各キーを接頭辞：
  command="<allowed command line here>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

8〜9年前、私は数百人のローカルユーザーがいる共有ユーザー環境で働いていましたが、キーにパスワードポリシーを適用する方法がなかったため、SSHキーベースのログインは無効になりました。シナリオを完全に制御している限り、今日のSSHキーは、単にパスワードを使用するよりも間違いなく優れています。

はい、インターネット上のほとんどのガイドは、パスワードなしのsshを安全に機能させるのではなく、機能させることに止まっています。このガイドは、リスクを軽減するために何ができるかを示すのに役立ちます。基本的に（記事を引用するため）：

• ジョブの単一目的ロールアカウントを作成します。つまり、dnssync各マシンのユーザー
• rootであることに頼るのではなく、可能であれば、そのユーザーがファイルを書き込み可能にする
• 本当に特権アクセスが必要なビットについては、それを実行するスクリプトを作成し、sudoを使用します
• パスフレーズのない鍵を制限するためのファイルの使用command=とfrom=オプションauthorized_keys
• ファイル転送を行うには、リモートマシンが読み取り専用になるように、受信側のマシンでrsyncを使用してスクリプトを記述します。
• これがリモートマシンから開始マシンへのアクセスが必要であることを意味する場合ssh-agent、2番目のパスフレーズなしのキーを作成するのではなく使用します。

sshキーにはいくつかの問題があります。

キーを取り消すための集中的な方法はありません。

キーにパスワードポリシーを適用する方法はありません（秘密キーは暗号化されていますか？暗号化されている場合、適切なパスワードで暗号化されていますか？）。

これらは、ケルベロスが解決する問題です。ただし、他のものを紹介します。つまり、実装がより複雑であり、展開および管理するには実際のユーザー管理インフラストラクチャが必要です。

いずれの場合でも、ssh authorized_keysはmorris-wormタイプの攻撃を許可しますが、.rサービスやtelnetよりもマイル（光年）優れています。

私が管理してきた環境では、サービスアカウントに最小限の特権を与えるための本当の責任者でした。

この場合、リモートサーバーのユーザーアカウントが、厳密に定義された小さな実行可能ファイルのセットの実行のみを許可されていることを確認することをお勧めします。これを実現するために、リモート側で複数のアカウントとsudoを使用できます。

この場合でも、ローカル権限昇格のバグが発生する可能性があるので、細心の注意を払い、セキュリティバグをしっかりと追跡してください。