SSH公開鍵認証とAPIアクセス用のユーザー名/パスワード
システムが起動するたびに、APIサーバーを定期的に呼び出すLinuxデバイスがあります。毎回、それ自体が認証されてから処理が行われます。
ユーザー名/パスワードを.configファイルに保存するか、公開id_rsa.pub SSHキーを作成できます。
私の質問は次のとおりです。なぜSSH認証はより良いと考えられているのですか？つまり、誰かが私のLinuxマシンにアクセスした場合、ユーザー名とパスワードの両方を読み取ることができますOR SSHキーと、これらの情報を自分のラップトップにコピーできます。
ここで何か不足していますか？ 注これらのユーザー名/パスワードはすべて私が生成し、ランダムな256ビット文字列になります。したがって、人々の典型的な推論は、弱くて予測可能なパスワードを使用することになるため、ここでは適用されません。
更新
次のアプローチはどうですか：
シード番号があり、これはmd5になります。この値はサーバーとすべてのマシンに保存されます。
これで、認証中に、クライアントは2つの文字列を送信します。
str1 = md5(timestamp + random());
str2 = md5(str1 + seed);
サーバーはこれら2つの数値を受け取り、それに応じてstr2からstr1を再計算します。 str2_from_server == str2の場合、トークンが生成されて返送されます。このトークンは、1回の使用で、または一定期間後に有効期限が切れます。
トークンはstr1 str2 tokenのテーブルキー/値ペアに保存され、二度と再利用できません（実際には、このテーブルはときどきクリアされるため、無限に大きくなることはありません）。
これはSSHよりも優れていますか？
いくつかの違いがあります。
まず、ユーザー名/パスワードを受け入れるようにAPIサーバーを設定することで（キーを介したアクセスのみを許可するのではなく、これはますますベストプラクティスになります）、一般に、セキュリティが低下する可能性があります。システム（または、さらに悪いことに、デフォルトのパスワードがハードコーディングされている可能性があるインストールしたサービス）は、サーバーへの侵入を可能にします。ブルートフォース攻撃は、システムに侵入したい人にとって突然の選択肢になります（パブリックIPでSSHサーバーを実行している場合、（保証でほとんどすぐに確認できます）。パスワードによるsshログインの無効化とログインキーの要求は、sshd_configで「PasswordAuthentication no」を設定し、sshdサービス（またはサーバー）を再起動するだけです。これは、最初のステップの1つとして構築するすべてのLinuxボックスで行います。さらに、（/ etc/sudeoersを適切に設定した場合）実際には何も使用しないため、非常に長くランダムなパスワードを設定することをお勧めします。 :)
次に、ssh keyオプションを使用すると、次のような方法でauthorized_keysファイルを簡単に設定できます。
- 特定のIPからのアクセスのみを許可します。そして
- アクセスするユーザー/スクリプトのみに特定のコマンドの実行を許可します。
このように、誰かがクライアントボックスを危険にさらしたとしても、盗まれたキーを使用して世界中のどこからでもサーバーにログインすることはできませんand、適切に設定すれば、あなたが許可した以外の何かのためにあなたのクライアントからログインするために使われることさえあります。たとえば、私はこれを使用して、特定のフォルダーの特定のオプションでrsync以外に何もできないアカウント/キーを設定します。したがって、キーが盗まれたとしても、攻撃者はクライアントマシンが実行しているコマンドを実行でき、クライアントのIPからしか実行できず、他には何も得られません。つまり、キーを取得しても、攻撃者はAPIサーバーを危険にさらすことはできません。パスワードベースのアカウントを制限して、特定のコマンドのみを実行したり、特定のIPからのログインのみを実行したりすることはできますが、これが実行されたのを見たことがないので、どれほど簡単かわかりません。
3番目に、APIサーバーへのアクセスを将来別の人/システムに許可する場合、およびパスワードを使用する場合、（皮肉なことに）キー配布の問題に遭遇します。つまり、ユーザーがログインできるように、初期アカウントパスワードを交換するための安全なチャネルが必要です。SSHキーを使用すると、公開キーを電子メールで送信するだけです（セキュリティは必要ありません）。メールが信頼できる限り、確実にメールを送信できます。確認する方法があり、アクセスを許可できます。
したがって、これがキーの使用に価値があることを確信していることを願っています（そして、実際には、パスワードのみのアクセスを使用してはなりません。キーまたはパブリックサービスの2FAが唯一の方法です:-)）。乾杯。
さて、ユーザー名/パスワードのアイデアを落とすと（この用途では安全ではありません）、ssh-clientが接続するchrootされた環境を実装できます。 ECDSAまたはRSA公開鍵暗号化を使用します（秘密鍵をアプリに同梱し、承認済みの鍵をchrootの外部に保存します）。
特に、クライアントが書き込む「ドロップボックス」を作成する場合、またはchroot環境からの書き込みアクセスのみでFIFO/LIFO特殊ファイルを作成する場合。クライアントに読み取りアクセスを一切与えずに、サーバーに安全に書き込むことができます。
アップロードしたいファイルだけの場合は、sshの組み込みsFTPクライアントを利用します。これは、chroot環境でシェルアクセスをまったく許可せずに、ファイルを直接アップロードできることを意味します。
「クライアント」のスクリプトを使用してssh接続をトリガーする場合、ssh.configファイルは必要ありません。スクリプトで必要なコマンドライン引数を指定するだけです。
なぜキーがセキュリティ面で優れているのかについては、SSHシステムがキーをどのように使用するかを調べるだけです。
- SSHクライアントはSSHサーバーを要求します（どのバージョンとキー交換/認証タイプをサポートしていますか）
- SSHサーバーは、機能と公開鍵トークンで応答します。
- SSHクライアントは、秘密鍵で署名された秘密の暗号化された「暗号化トークン」（何らかの暗号化マジックを使用した公開鍵トークンの操作）で応答します。
- SSHサーバーは、署名を認証し（公開キーがメッセージを復号化）、暗号化トークンを検証し、クライアントと同様の方法を使用して、独自の暗号化トークンに基づいて応答します。
- SShクライアントは、受信した暗号化トークンを検証します。
- SSHサーバーは、新しいキーを使用して安全なトンネルを設定します。シェルを起動します。
ssh-clientは安全なトンネルエンドポイントを設定し、シェルプロキシを開始します。
yaay ssh接続が確立されました。
私はあなたが何をしようとしているのかをよりよく理解するために、SSHとキーとchrootについて読むことを勧めます。
SSH承認がより適切と見なされるのはなぜですか？つまり、誰かが私のLinuxマシンにアクセスした場合、ユーザー名とパスワードの両方を読み取ることができますOR SSHキーと、自分のラップトップにこれらの情報をコピーできます。
はい、本当です。誰かがあなたのマシンに完全にアクセスできるようになれば、あなたはどちらかの方法で問題を抱えています。
ここで何か不足していますか？
はい。攻撃者がマシンへのフルアクセスをまだ取得していないすべての状況。 SSHキーでは不可能なユーザー名/パスワード認証で可能な攻撃が簡単に実装されています。