私は、Debian への SSH による公開キー ログインのみを許可するという一般的な慣例に従いましたが、何らかの理由で ~/.ssh/ フォルダーの権限を誤って変更してしまいました (所有者が root になったと思います)。その後、openSSH はログインを拒否しました! (サーバーは別の国にあり、リモート/KVM コンソールはありませんでした)
この設定は非常に脆弱だと思います。これを防ぐ方法はありますか? 次回ログイン時に警告を表示するだけでいいでしょうか?
解決策がない場合は、他の人が何を言おうと、バックアップとして強力なログイン パスワードを設定する必要があります。
同様のロックアウトの質問が見つかりましたが、iptable/構成の変更が根本的な原因でした。 SSH と iptables の設定時にロックアウトされないようにする 構成を変更しなかったので、ロックアウトは予想していませんでした。
答え1
ホストを回復するには、代替のアクセス方法が必要です。インターネット経由の SSH では、ネットワーク アクセス、ファイアウォールの許可ルール、実行中および構成された SSHD、保護されたキー ファイルなどが正常に動作している必要があります。これらのいずれかが壊れると、アクセスできなくなります。最も信頼性の高い帯域外アクセスは、ホストの IP ネットワークが動作しているかどうかに依存しません。
VM の場合は、シャットダウンして、ディスクを他の稼働中のインスタンスに接続して修復します。理想的ではありませんが、ディスクにアクセスできる必要があります。
データのオフホスト バックアップにより、新しい代替ホストを作成できます。SSH アクセスが失われたという理由だけで破棄して再構築するのは愚かなことのように思えるかもしれませんが、回復オプションとして残ります。
そもそも問題を防ぐには、sshd 構成 ( sshd -T -fOpenSSH の場合) の構文チェックではすべてを検出できるわけではありません。エンドツーエンドのテストは、ポート番号以外はすべて同じで、別の sshd を別のポートで起動することで実行できます。これにリモートで接続して、動作しているかどうかをテストします。残念ながら、このような注意を払っても、ホーム ディレクトリの権限変更によって誤って ssh ファイルが保護されなくなるなど、意図しないものを検出することはできません。または、キーワードssh_configによってIP が変更され、有効性が変わる可能性があります。Match
パスワードは依然としてひどい認証メカニズムです。