ConoHa VPSのKUSANAGIでrootパスワードをリセットする方法
ConoHa VPSのKUSANAGIでrootパスワードをリセットする方法
ConoHa VPS上で稼働するKUSANAGIのrootパスワードを再設定するには、VNCコンソールとシリアルコンソールを併用すると、GRUBを捕捉しやすくなります。
先にシリアルコンソールを接続しておき、別ウィンドウのVNCコンソールからCtrl+Alt+Delを送信して再起動します。
再起動の直後にシリアルコンソールでGRUBを捕捉し、rd.breakからrootファイルシステムへ入ってパスワードを変更します。
この記事は、RHEL 9系の手順をAlmaLinux 9上のKUSANAGIで実行した記録を、固有情報を除いて整理したものです。
想定する状況
次のような状態を想定しています。
- 一般ユーザーではSSH接続できる
- そのユーザーには
sudo権限がない - rootパスワードを確認できない
- root用のSSH公開鍵が未登録、またはrootのSSH接続を確認できない
- ConoHaコントロールパネルへログインできる
ConoHaコントロールパネルから、設定済みのrootパスワードそのものを表示することはできません。 既存の認証手段でrootになれない場合は、コンソールから起動処理へ介入して再設定します。
作業前の準備
この操作ではサーバーを再起動するため、公開サイトや関連サービスが数分から十数分停止します。 作業日時と停止時間を関係者へ伝え、実行前に了承を得てください。
少なくとも、次のバックアップと確認を済ませます。
- WordPressのファイル一式
- データベースのダンプ
- バックアップファイルの破損確認
- 復旧に必要な接続情報と手順
ConoHaアカウントでは多要素認証を有効にし、第三者がコンソールを開けない状態にします。 コンソールへ入れる人は、SSH認証を迂回してrootパスワードを変更できるためです。
新しいrootパスワードは、パスワードマネージャーで十分に長いランダムな値を生成します。 値はチャット、作業ログ、コマンド履歴、スクリーンショットへ残さず、入力欄へ直接入力してください。
停止してから起動する方法ではGRUBに間に合わなかった
最初に試しやすいのは、コントロールパネルでVPSを停止し、コンソールを開いてから起動する方法です。
しかし、停止や起動に伴ってコンソール接続が切れると、再接続している間にGRUBの待ち時間が終わります。 起動後に接続できても、すでに通常のログイン画面まで進んでいることがあります。
停止と起動を使うと、コンソールが切断されたまま起動処理が進む場合があります。
そこで、シリアルコンソールを接続したまま、VNCコンソールからゲストOSへ再起動操作を送る方法へ切り替えます。
VNCとシリアルコンソールを併用する手順
1. シリアルコンソールを先に接続する
ConoHaコントロールパネルのサーバー詳細からコンソールを開き、シリアルコンソールへ接続します。 画面にログインプロンプトが表示されるところまで確認し、このウィンドウは閉じずに残します。
再起動前からシリアルコンソールを接続しておくと、起動直後のGRUBを確認しやすくなります。
次に、別ウィンドウまたは別タブでVNCコンソールを開きます。 以降は、VNCで再起動を実行し、シリアルでGRUBを操作します。
2. VNCからCtrl+Alt+Delを送信する
VNCコンソール上部の「特殊キー」を開き、Ctrl+Alt+Delを選びます。
ローカルPCのキーを直接押すのではなく、コンソールの特殊キーメニューから送信します。
VNCから再起動を送信し、待機中のシリアルコンソールで起動直後の画面を捕捉します。
送信したら、すぐにシリアルコンソールへ戻ります。 キー入力を受け付けるように、シリアルコンソールの黒い画面を一度クリックしておきます。
3. GRUBで起動項目を編集する
GRUBメニューが表示されたら、通常起動に使うカーネルを選んだ状態でeを押します。
レスキュー用の項目を選ぶ必要はありません。
編集画面でlinuxから始まる行を探します。
その行の末尾へ半角スペースを入れ、次の起動オプションを追加します。
rd.break
編集後はCtrl+Xで起動します。
ブラウザがCtrl+Xをショートカットとして処理してしまう場合は、GRUBの代替キーであるF10を押します。
4. switch_rootプロンプトでrootファイルシステムへ入る
rd.breakが反映されると、通常のログイン画面ではなくswitch_root:/#プロンプトで停止します。
このプロンプトでは、インストール済みOSのルートが/sysrootへ読み取り専用でマウントされています。
書き込み可能な状態で再マウントし、インストール済みOSへchrootします。
mount -o remount,rw /sysroot
chroot /sysroot
5. rootパスワードを変更する
次のコマンドを実行します。
passwd root
新しいパスワードを2回入力します。
入力中の文字は画面へ表示されませんが、そのまま入力してEnterを押します。
値をクリップボード履歴、テキスト送信機能、スクリーンショットへ残さないでください。 共有画面や操作録画を使っている場合は、入力前に記録を止めます。
2回の入力が一致しない場合は、Sorry, passwords do not match.と表示され、変更は完了していません。
もう一度、同じ新パスワードを2回入力します。
BAD PASSWORDはパスワード品質に関する警告であり、環境のポリシーによって扱いが異なります。
警告だけで成否を判断せず、強いパスワードへ変更したうえで、次の完了メッセージを確認します。
passwd: all authentication tokens updated successfully.
このメッセージが表示されるまでは、パスワードが変わったと判断できません。
6. 必要な場合だけrootへ承認済み公開鍵を登録する
rootのSSH公開鍵認証が運用上必要な場合だけ、管理者が承認した公開鍵を登録します。 この操作は任意であり、パスワードの再設定だけが目的なら省略できます。
作業前に、ローカルPCではなく、サーバー上の一般管理ユーザーのホームへ、承認済み公開鍵を1行だけ保存します。
このファイルは、chroot /sysroot後にも見えるインストール済みOS内のパスへ置く必要があります。
以下の例は/home/admin/approved-root-key.pubを使うため、adminを実際の一般管理ユーザー名へ置き換えます。
秘密鍵、パスワード、複数の公開鍵、未確認の公開鍵を入れてはいけません。
再起動前に、公開鍵ファイルが1行だけであることと、期待する指紋との一致を外部共有されない画面で確認します。 指紋の値は作業ログやスクリーンショットへ残しません。
approved_key_file=/home/admin/approved-root-key.pub
install -d -m 700 /root/.ssh
touch /root/.ssh/authorized_keys
cat "$approved_key_file" >> /root/.ssh/authorized_keys
sort -u -o /root/.ssh/authorized_keys /root/.ssh/authorized_keys
chown -R root:root /root/.ssh
chmod 600 /root/.ssh/authorized_keys
登録後に、所有者と権限を確認します。
stat -c '%U:%G %a %n' /root/.ssh /root/.ssh/authorized_keys
期待する結果は、/root/.sshがroot:root 700、authorized_keysがroot:root 600です。
通常起動後には、登録された公開鍵と承認済み公開鍵の指紋が一致することも確認します。
登録と確認に成功した後で、一時ファイルを削除します。
rm -f -- "$approved_key_file"
unset approved_key_file
この作業は、sshdで無効になっているrootログインを有効にするものではありません。
既存のSSHポリシーを変更せず、rootの直接SSH接続を許可するかどうかは別に判断します。
7. SELinuxの再ラベルを予約して起動を続ける
パスワードや/root/.sshの変更後は、SELinuxのラベルを付け直すためのファイルを作成します。
touch /.autorelabel
続けてchrootとrd.breakのシェルを順に終了します。
exit
exit
SELinuxの再ラベル処理が始まり、完了後に再起動します。 ファイル数によっては数分以上かかるため、画面が止まったように見えても強制停止しないでください。
再ラベルと再起動が終わるまで待ち、通常のログインプロンプトへ戻ることを確認します。
再起動後の確認
再起動できたことだけでは、作業完了とは判断できません。 認証、既存ユーザー、KUSANAGIのサービス、公開サイトを順に確認します。
root認証
パスワード変更の成否は、ConoHaコンソールでrootと新しいパスワードを使ってログインして確認します。
公開鍵によるSSHログインの成功は、変更したパスワードの確認にはなりません。
rootのSSH公開鍵認証を設定した場合は、パスワード確認とは別に、運用上許可されたSSH方式でもログインを確認します。 ログイン後は、次のコマンドでrootになっていることを確かめます。
id
期待する結果にはuid=0(root)が含まれます。
rootのSSHログインを許可していない環境では、コンソールだけで確認します。
既存ユーザーのSSH接続
作業前から使っていた一般ユーザーでもSSH接続します。 rootの復旧と引き換えに、既存の接続方法を壊していないことを確かめるためです。
KUSANAGIと周辺サービス
失敗しているsystemdユニットを確認します。
systemctl --failed --no-pager
systemctl --type=service --state=running --no-pager | grep -E 'kusanagi|nginx|php-fpm|mariadb|sshd'
KUSANAGIでは、nginx.serviceではなくバージョン番号付きのユニット名が使われる場合があります。
nginx.serviceだけを確認して停止と判断せず、実際にインストールされているユニット名を一覧から特定してください。
ローカルのHTTP応答も確認します。
curl -I --max-time 10 http://127.0.0.1/
構成によってHTTPSやHostヘッダーが必要なため、実際のKUSANAGIプロファイルに合わせて確認先を変えます。
公開サイトとコントロールパネル
最後にブラウザで公開サイトを開き、レイアウト、画像、主要な導線を目視します。 同時にConoHaコントロールパネルで、VPSが起動状態へ戻っていることも確認します。
HTTP応答だけでなく、ブラウザでページが崩れていないことまで確認します。
コンソールでログインを確認した新しいrootパスワードは、作業直後にパスワードマネージャーへ保存します。 保存後は、一時的なメモやクリップボード履歴に値が残っていないことを確認します。
トラブルシューティング
| 症状 | 確認と対処 |
|---|---|
| コンソール画面が見つからない | ConoHaのコンソールは別のポップアップで開くため、ブラウザのポップアップ許可とウィンドウ一覧を確認します。 |
| 停止後にコンソールが切断され、GRUBに間に合わない | シリアルコンソールを先に接続し、別ウィンドウのVNCからCtrl+Alt+Delを送ります。 |
| GRUBメニューがすぐ消える | 再起動操作の直前にシリアル画面をクリックし、キー入力の送信先を確認します。 |
Ctrl+Xで起動できない | ブラウザに奪われている可能性があるため、GRUB編集画面でF10を使います。 |
switch_root:/#が表示されない | linux行の末尾へrd.breakが追加されているかを見直します。 |
passwdで不一致と表示される | その入力は破棄されているため、同じ新パスワードを続けて2回入力します。 |
BAD PASSWORDと表示される | 強いランダムパスワードへ変更し、成功メッセージが出たかで成否を判断します。 |
/.autorelabel後の起動が長い | SELinuxの再ラベルが終わるまで待ち、途中で強制停止しません。 |
nginx.serviceがinactiveになる | バージョン番号付きのnginxユニットを含め、実際のユニット名を確認します。 |
作業後に残す記録
作業記録には、日時、停止時間、実行したコマンド、確認したサービス、公開サイトの確認結果を残します。
次の情報は記録へ含めません。
- rootパスワードの値
- 秘密鍵
- 公開鍵の指紋
- サーバーのIPアドレスやホスト名
- VPSやアカウントを特定できる識別子
- コンソール接続用URL
スクリーンショットを外部へ公開するときは、ブラウザのアドレスバー、アカウント表示、IPアドレス、ホスト名、ファイルシステムのUUIDまで確認します。 黒塗りだけに頼らず、固有情報が写っていない画面だけを選ぶ方が安全です。