デフォルトのホームディレクトリのキーのパスに書き込めない
2024年12月に投稿された元のZimaOSに関する質問は、通常の~/.ssh/authorized_keysの運用方法についてのものでした。システムの読み取り専用レイアウトにより、そのファイルを通常どおり作成できませんでした。トピック内で行われた初期の試行では、確実に持続する回避策は確認されていないため、完成した解決策として扱うべきではありません。
後のZimaOS 1.7の報告では/etcのキーファイルを使用
2026年8月、別のコミュニティメンバーがZimaOS 1.7で機能する方法を報告しました。公開鍵を/etc/ssh/authorized_keysに配置し、SSHデーモンがそのファイルを参照するように設定する方法です。基本的な設定は次のとおりです。
AuthorizedKeysFile /etc/ssh/authorized_keys管理者権限でファイルを作成し、1行につき1つの完全な公開鍵を追加して、他のユーザーが変更できない権限を設定します。その後、SSHサーバーの設定を更新し、SSHデーモンを再起動します。この投稿は公式の互換性声明ではなく、コミュニティによる結果であるため、変更を加える前に、インストールされているZimaOSのバージョンで実際の設定ファイルとサービス名を確認してください。
パスワード認証を無効にする前にキーによるログインをテスト
テスト中は現在のSSHセッションを開いたままにし、ZimaOSのウェブターミナルにもアクセスできる状態を維持してください。別のターミナルを開き、公開鍵によって新しいセッションを正常に開始できることを確認します。オプションのセキュリティ強化設定を検討するのは、そのテストが終わってからにしてください。
PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM no
PermitRootLogin no
PermitEmptyPasswords noこれらの設定は、キーのパスを変更するよりも広範な影響を及ぼします。キーによるログインテストに成功する前に適用すると、リモート管理から締め出される可能性があります。また、特にシステムがPAMや管理されたrootログインの運用に意図的に依存している場合は、すべての環境に適しているとは限りません。
手順はバージョン固有のものとして扱う
この議論はほぼ2年間にわたっており、確認済みの報告ではZimaOS 1.7が明記されています。同じファイルがアップグレード後も維持されることや、以前のリリースで同じように動作することは実証されていません。変更内容を記録し、OSのアップデート後にSSHアクセスを再テストしてください。
FAQ
ZimaOSで~/.ssh/authorized_keysを作成できないのはなぜですか？
元のケースでは、ファイルシステムのその部分が読み取り専用でした。後の回避策では、通常のホームパスを書き込み可能にしようとするのではなく、デーモンが使用するキーの場所を変更しました。
動作したZimaOS 1.7の方法では、公開鍵をどこに保存しましたか？
/etc/ssh/authorized_keysを使用し、AuthorizedKeysFileがそこを参照するように設定しました。
パスワード認証はすぐに無効にすべきですか？
いいえ。まず復旧用のセッションを利用できる状態にして、新しいキー認証によるログインを確認してください。他の認証方式を無効にするのは、そのテストが完了し、かつシステムのアクセス方針に適合する場合に限ります。
