クイズ5. SSHによるリモートアクセス

サポート対象バージョン: Ubuntu Server 24.04 LTS（主対象）、Rocky Linux 9（代替） 最終更新日: 2026年9月15日

レッスンと主な情報源 | コース

最も安全で根拠のある回答を選び、確認すべき証拠を説明してください。ここにあるコマンドは、破棄可能なVM上で解釈するための演習です。

1. Ubuntu 24.04ではssh.socketがactiveですが、Rockyのガイドにはsshd.serviceとあります。どうすべきですか？

   • A) 両方のディストリビューションで同じ状態にするため、すべてのソケットを無効にする
   • B) 実行ファイル名がsshdなので、すべての環境でsshd.serviceを使う
   • C) ゲストOSにインストール済みのunitを確認する。Ubuntuではssh.serviceを使い、ソケットによる起動を使う場合がある。Rockyではsshd.serviceを使う
   • D) リスナーを確認する前にSSHポートを変更する

回答を表示

回答: C

解説: 実行ファイル名とサービスunit名が一致するとは限りません。Ubuntuではソケット起動がリスナーを管理していることがあり、無条件に無効化したりバインド設定を変更したりすると接続できなくなる可能性があります。このレッスンでは、既存のlistenアドレスを変更せずに、構文、サービス/ソケットの状態、TCP 22を確認します。

2. 初めて接続すると、クライアントにED25519ホストフィンガープリントが表示されました。意図した相手だと信頼するには、どのように比較すべきですか？

   • A) ハイパーバイザーのコンソール経由で確認したサーバーの公開ホスト鍵と、フィンガープリント全体を比較する
   • B) ユーザーが新しく生成した公開鍵と比較する
   • C) IPアドレスの末尾が.20なので受け入れる
   • D) 同じ信頼できない経路でssh-keyscanを実行し、返された値を受け入れる

回答を表示

回答: A

解説: ホスト鍵はサーバーを識別し、ユーザー鍵はユーザーアカウントを認証します。信頼できるコンソールがあれば、独立した経路で比較できます。スキャンで鍵を収集することはできますが、鍵の所有者を認証することはできません。不一致がある場合は、チェックを回避せずVM/アドレスやIDが変わった可能性を調査してください。

3. ユーザー鍵をインストールする際、サーバーに置くものはどれですか？

   • A) 秘密鍵ファイルid_ed25519とそのパスフレーズ
   • B) サーバーの秘密ホスト鍵をコピーして自分のホームディレクトリに置く
   • C) アカウントのパスワードのスクリーンショット
   • D) 公開鍵のid_ed25519.pub行を、既存のエントリを置き換えずに正しいアカウントのauthorized keysへ追加する

回答を表示

回答: D

解説: 秘密鍵はクライアント上に置き、空でないパスフレーズで保護します。ssh-copy-id -iを使うと、既存の認証方法でインストールする公開鍵を選択できます。初期設定用のSSHを使えない場合は、コンソール経由で公開鍵の行を追記してください。コピーのためにパスワード認証を有効にしたり、秘密鍵を転送したりしてはいけません。

4. SSHセッションを1つ開いたままです。パスワード認証とkeyboard-interactive認証を無効にする前に、何が必要ですか？

   • A) 何も必要ない。既存の接続が将来のログインも成功することを証明している
   • B) 接続共有を無効にした状態で、2つ目の独立した鍵のみの接続を成功させ、必要な管理SSH経路も確認する
   • C) 最初に表示されたauthorized key以外をすべて削除する
   • D) テストを現実的にするため、コンソールを閉じる

回答を表示

回答: B

解説: すでに認証されたセッションや多重化されたセッションがあると、新しいログイン経路の故障が隠れる場合があります。明示的な鍵、IdentitiesOnly、公開鍵のみの認証、接続共有なしを指定してください。秘密鍵のパスフレーズはクライアント側で入力する想定のままです。復旧に備え、コンソールと元のセッションを開いたままにしてください。

5. 後から読み込まれるdrop-inにPasswordAuthentication noがありますが、sshd -T -Cではラボユーザーに対してyesと表示されます。適切な対応はどれですか？

   • A) 先に設定された値、Includeの順序、該当するMatchブロックを調査する。ファイル名が後だから勝つと思ってreloadしない
   • B) 表示された有効値は関係ないとみなす
   • C) 同じ設定をさらに10個のファイルへ追加する
   • D) drop-inを読み直させるためにネットワークを再起動する

回答を表示

回答: A

解説: OpenSSHでは最初に設定された値を使う動作や接続ごとのMatchルールがあり、「最後のファイルが勝つ」とは限りません。-Cには、有効な設定を評価するユーザー、送信元、ローカルの接続先を指定します。構文チェックだけでは意図したポリシーが有効であることを証明できません。優先順位が意図どおりであると確認できない場合は、コースが作成したファイルだけを削除してください。

6. SSHの強化に関する正しい説明はどれですか？

   • A) PasswordAuthentication noを設定すると、keyboard-interactive認証も常に無効になる
   • B) PermitRootLogin noを設定するとsudoも使えなくなる
   • C) password、keyboard-interactive、public-key、root-loginの値を明示的に確認し、通常ユーザーの鍵アクセスとsudoを維持する
   • D) 鍵認証を使うには、PAMを全体的に無効にする必要がある

回答を表示

回答: C

解説: passwordとkeyboard-interactiveは別々の認証方式です。rootで直接SSHログインすることと、通常ユーザーがsudoを使うことも別です。このレッスンではPAMを無効にしません。グローバルな認証設定を変更する場合は、ラボのIPだけでなく、必要な管理アカウントや経路をすべて確認してください。

7. reloadは成功しましたが、新しいログインに失敗します。適切な範囲での復旧方法はどれですか？

   • A) ファイアウォールをflushし、/etc/sshを削除する
   • B) 他の新しい管理者変更も上書きする可能性があっても、古いSSHディレクトリ全体を復元する
   • C) 直ちに再起動し、コンソールを破棄する
   • D) サーバーコンソールを使って自分が作成したdrop-inだけを削除し、構文と有効なベースラインを確認してからreloadし、新しい接続を再テストする

回答を表示

回答: D

解説: 自分が作成したファイルだけを対象にすれば、無関係な設定を置き換えずに正確な逆操作ができます。通常ユーザー、root、記録された管理ケースについて、有効な設定結果を比較してください。並行して変更が入っていた場合は、古いディレクトリを無条件に戻さず変更を調整します。既存セッションだけでは復旧を検証できません。

8. コース用の公開鍵を既存のauthorized_keysに追加しました。最終クリーンアップではどうすべきですか？

   • A) ~/.sshを再帰的に削除する
   • B) コースのコメントとフィンガープリントで特定できる行だけを削除し、他の鍵を保持し、記録した権限を復元する。その後、失効させてから専用のクライアント鍵ファイルを削除する
   • C) レッスンが終わったので空のファイルで上書きする
   • D) クライアント側の秘密鍵を先に削除し、サーバーの認可も自動的に取り消されたとみなす

回答を表示

回答: B

解説: クライアント側の鍵を削除しても、サーバーに登録された公開鍵は失効しません。サーバー上の該当エントリを失効させてから、無関係な変更を保持してください。レッスンが作成したディレクトリで空の場合に限り、ディレクトリも削除します。パッケージのロールバックは別作業であり、完全な復元が必要ならゲストのスナップショットを使います。

レッスンに戻る | 次へ: ホストセキュリティ