Ubuntu VPSのrootパスワードを変更する方法

Ubuntu で VPS の root パスワードを変更する方法

Ubuntu で VPS (virtual private server) の root パスワードを変更するには、sudo を実行できるユーザーとして SSH (secure shell) セッションを開き、sudo passwd root を実行します。新しいパスワードを 2 回入力します。古いパスワードは求められません。sudo によって、すでに本人確認が済んでいるためです。自分のログインパスワードを変更する場合は、引数なしで passwd を実行します。最初に現在のパスワードを求められます。

passwd                  # your own password
sudo passwd deploy      # another user's password
sudo passwd root        # root's password

操作はこれだけです。以下では、問題が発生しやすい点を説明します。セッションを失って修正できなくなる前に、新しいパスワードが機能することを確認する方法、スクリプトからパスワードを設定する方法、意図的にパスワードを期限切れにする方法、パスワードをすでに失った場合に再びログインする方法を扱います。

パスワードを変更する前に、2 つ目のセッションを開く

今すぐ 2 つ目の SSH セッションを開き、接続したままにします。このガイドで発生する問題のほとんどは、認証済みのシェルが 1 つでも残っていれば 2 分で修正できます。最後のセッションを閉じてしまうと、コンソールへの接続が必要になる場合があります。

すでに開いているシェルは、そのシェルが属するアカウントのパスワードを変更、ロック、または期限切れにした後も動作します。SSH はログイン時に認証情報を確認し、その後は再確認しないためです。例外は sudo です。sudo は、キャッシュ済みの認証情報の有効期限が切れると、PAM（プラグ可能な認証モジュール）を通じてパスワードを再確認します。Ubuntu では、デフォルトの有効期限は 15 分です。この時間は、最後にプロンプトが表示されてからの経過時間ではありません。sudo -v が、再入力を求めずにキャッシュ済みの認証情報を更新するためです。そのため、新しいパスワードが初めて実際に検証されるのは、ログイン時ではなく、次に sudo がパスワードを要求したときです。

1 つ目のセッションを開いたまま、2 つ目のセッションで新しいパスワードをテストします。

passwd で自分のパスワードを変更する

passwd

Changing password for deploy.
Current password:
New password:
Retype new password:
passwd: password updated successfully

passwd: password updated successfullyだけが、/etc/shadowのハッシュが置き換えられたことを示す出力です。それ以外の場合、古いパスワードがそのまま残っています。

ここでは2つの失敗が発生します。passwd: Authentication token manipulation errorに続いてpasswd: password unchangedが表示される場合、入力した現在のパスワードが間違っているか、/etc/shadowを保持するファイルシステムに書き込めません。後者は、リカバリモードでは通常の状態です。You must choose a longer password.は/etc/pam.d/common-password内のpam_unixに由来し、一般ユーザーに対して長さと類似性のチェックを適用します。

ほとんどの VPS イメージでは、デフォルトアカウント（ubuntu、またはプロバイダーが用意した名前）にはパスワードがなく、SSH key だけが設定されています。passwdには照合する現在のパスワードがないため、最初のプロンプトを通過できません。代わりにsudo passwd $USERを使用してください。イメージの sudoers drop-in file により、そのアカウントはパスワードなしでsudoを実行できるためです。

sudo passwd で別のユーザーのパスワードを変更する

sudo passwd deploy

root には古いパスワードの入力を求められません。また、pam_unix は通常のユーザーに適用される強度チェックを回避します。そのため、root はユーザー自身では設定できないパスワードも設定できます。

ロックは別の操作です。sudo passwd -l deploy は保存されたハッシュの前に ! を付けるため、どのパスワードも一致しなくなります。sudo passwd -u deploy でこの文字を削除できます。sudo passwd -S deploy で状態を確認します。

パスワードをロックしても、そのユーザーのログインは停止しません。~/.ssh/authorized_keys にある鍵は引き続き使用できます。公開鍵認証ではパスワードハッシュを確認しないためです。アカウントを完全に停止するには、アカウント自体を期限切れにします。

sudo usermod --expiredate 1 deploy

これにより、アカウントの有効期限が 1970 年の日付に設定されます。そのため、sshd は提示された認証情報の種類にかかわらずログインを拒否します。sudo usermod --expiredate '' deploy で元に戻せます。

passwd -d は使用しないでください。これはパスワードをロックするのではなく、空のパスワードを設定します。nullok が PAM スタックに残っている古いリリースでは、空のパスワードを誰でも使用できます。

VPS で root にパスワードは必要ですか？

Ubuntu では root がロックされた状態でリリースされます。/etc/shadow はハッシュの代わりに ! を保持し、sudo passwd -S root は root L で始まる行を出力します。root のパスワードを設定するまで、パスワードを使って root としてログインすることはできません。そのため、イメージでは sudo を使用できるユーザーが提供されます。root ではなく VPS で最小権限のユーザーアカウントを使用する運用を基本にしてください。

root パスワードを設定すると、プロバイダーのコンソールからログインできるようになります。コンソールはネットワークスタックの下で仮想マシンに接続するため、sshd の設定を誤った場合やファイアウォールルールに問題がある場合でも機能します。一方で、代償もあります。root にパスワードが設定されていると、GRUB のリカバリーメニューにある root シェルは root パスワードを要求します。忘れたパスワードをリセットするためのツールが、その同じパスワードの背後に置かれることになります。

root パスワードを設定しても、SSH 経由で root としてログインできるようにはなりません。Ubuntu では PermitRootLogin prohibit-password が設定されており、鍵認証のみが許可されます。サーバーで実際に使用されている設定を確認してください。

sudo sshd -T | grep -i permitrootlogin

sshd -T は、Include 行以降をすべて解決した後の有効な設定を出力します。そのため、/etc/ssh/sshd_config.d/ に drop-in ファイルがある場合に、実際の設定を確認する唯一の確実な方法です。

スクリプトから chpasswd でパスワードを設定する

passwd は端末から入力を読み取るため、スクリプトから操作できません。chpasswd は標準入力から、1 行に 1 つずつ user:password の組み合わせを読み取ります。

printf '%s:%s\n' 'deploy' "$NEW_PASSWORD" | sudo chpasswd

この方法は動作しますが、平文のパスワードがシェルの履歴と CI（継続的インテグレーション）のログに残ります。先にハッシュ化してください。

HASH=$(openssl passwd -6)
printf '%s:%s\n' 'deploy' "$HASH" | sudo chpasswd -e

openssl passwd -6 はエコーを無効にしてパスワードを 2 回入力するよう求め、その後、$6$ で始まる SHA-512 crypt ハッシュを出力します。-e は、2 番目のフィールドがすでにハッシュ化されていることを chpasswd に伝えるため、その内容が変更されずに /etc/shadow へコピーされます。このハッシュはリポジトリや CI 変数に安全に保存できます。平文のパスワードが、入力したマシンの外へ出ることもありません。

Ubuntu 24.04 では、passwd で新しいパスワードを設定すると yescrypt（$y$）でハッシュ化されます。一方、openssl passwd -6 では SHA-512 が使用されます。libxcrypt は両方の形式を読み取るため、どちらもログイン時に検証できます。両者を混在させても問題ありません。openssl passwd -6 は 18.04 以降のすべての Ubuntu LTS リリースで同じように動作しますが、chpasswd -c YESCRYPT は異なります。20.04 の古い shadow パッケージは、その方式名を認識しません。Ubuntu 16.04 は例外です。このリリースの OpenSSL 1.0.2 には -6 オプションがありません。これらのハッシュはリリースをまたいでも使用できるため、24.04 のサーバーを 26.04 にアップグレードする際に、全員のパスワードをリセットする必要はありません。

パスワードが実際に変更されたことを確認するにはどうしますか？

まずメタデータを確認し、次にログインして実際に検証します。

sudo passwd -S deploy

deploy P 08/01/2026 0 99999 7 -1

2 番目のフィールドは状態を示します。P は使用可能なパスワード、L はロック中、NP はパスワードが設定されていない状態です。日付はパスワードを最後に変更した日なので、今日の日付になっているはずです。その後の数値は、以下で説明する有効期限管理のフィールドです。

実環境で最も安全に確認する方法は、sudo 自体を使用することです。sudo -k はキャッシュされたタイムスタンプを破棄し、sudo -v は新しい入力プロンプトを強制します。ここで新しいパスワードが受け付けられれば、PAM がそのパスワードを受理したことになります。現在のセッションには何も変更がありません。

sudo -k && sudo -v

別のアカウントをテストするには、権限のない shell から su - deploy を実行します。sudo su - deploy は実行しないでください。root にパスワードは要求されないため、このテストでは何も検証できません。パスワードが間違っている場合は su: Authentication failure が表示されます。

本当のテストは、現在の作業セッションを開いたまま、ラップトップから新しい SSH ログインを試すことです。

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

ここで Permission denied (publickey). は、サーバーがパスワード認証を提示しなかったことを意味します。そのため、パスワードを変更してもログインできません。Permission denied, please try again. は、サーバーがパスワード認証を提示したものの、入力したパスワードを拒否したことを意味します。

次回のログイン時に chage でパスワード変更を強制する

sudo chage -d 0 deploy

-d 0 は最終変更日を epoch に設定するため、PAM はパスワードを期限切れとして扱います。次回の対話的なログインでは、シェルを開始する前に現在のパスワードと新しいパスワードの入力を求められます。sudo passwd -e deploy もまったく同じ動作をします。

パスワードで対話的にログインするアカウントだけに使用してください。期限切れのパスワードは、鍵ベースのログインにも影響します。鍵で認証した場合でも、sshd は PAM の account ステージを実行するためです。スクリプトから実行した ssh deploy@203.0.113.10 'systemctl restart app' は、コマンドを実行する前に次のエラーで失敗します。

Password change required but no TTY available.

リモートコマンドは実行されず、ssh は 0 以外の終了コードで終了します。呼び出し元のスクリプトが set -e または明示的なチェックでエラー時に停止する設定になっていない場合、その後の行も実行されます。その結果、再起動が実行されたかのようにジョブが完了することがあります。

パスワードの有効期限関連フィールドの意味

sudo chage -l deploy

Last password change                                    : Aug 01, 2026
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

これらの数値は、/etc/shadow にあるそのユーザーの行のフィールド 4 から 8 です。最小日数 (chage -m) は、ユーザーが再度パスワードを変更するまで待つ必要がある期間です。強制変更の直後に、以前のパスワードへ戻す操作を防ぎます。最大日数 (chage -M) は、パスワードが有効である期間です。警告日数 (chage -W) は、ログイン時に警告を表示し始める時点です。非アクティブ日数 (chage -I) は、パスワードの有効期限が切れた後も、パスワードを完全に受け付けなくなるまでの猶予期間です。アカウントの有効期限 (chage -E) は固定された日付であり、パスワードとは別に管理されます。

sudo chage -M 90 -W 14 deploy

ポリシーで必要な場合にだけ設定してください。NIST (米国国立標準技術研究所) は 2017 年以降、パスワードを定期的に期限切れにする運用を推奨していません。定期変更を求めると、同じパスワードに予測可能な変更を加える運用につながるためです。パスワードが漏えいした証拠がある場合に、変更を強制することを推奨しています。パスワードマネージャーで管理する長く一意のパスワードと、鍵ベースの SSH の組み合わせは、90 日ごとの変更よりも有効です。

root パスワードを失った場合の対処

サーバー上のいずれかのアカウントが sudo を実行できる場合、復旧するものはありません。sudo passwd root で新しいパスワードを設定できます。難しいのは、機能するログイン手段がまったくない場合です。

以下の操作には、プロバイダーのコンソールが必要です。多くの管理パネルでは、VNC（virtual network computing）またはシリアルコンソールとして表示されます。このコンソールはネットワークスタックの下にある仮想マシンへ接続するため、sshd の設定やファイアウォールルールの影響を受けません。

1. 管理パネルからサーバーを再起動し、コンソールを監視します。
2. GRUB メニューを表示します。クラウドイメージでは通常 GRUB_TIMEOUT=0 が設定されているため、BIOS ブートでは再起動が始まったら Shift を押し続けます。UEFI ブートでは、再起動が始まったら Esc を繰り返し押します。
3. Advanced options for Ubuntu を選択し、続いて (recovery mode) で終わるエントリを選択し、最後にリカバリーメニューで root を選択します。
4. 最初に mount -o remount,rw / を実行します。リカバリー環境では root ファイルシステムが読み取り専用でマウントされるため、これを実行しないと、書き込みできず passwd: Authentication token manipulation error という理由で passwd が失敗します。/etc/shadow には書き込めません。
5. 対象のアカウントに対して passwd ubuntu を実行し、管理パネルから再起動します。

root にすでにパスワードが設定されており、それを失った場合、そのリカバリーシェルではパスワードの入力を求められるため、この方法は使えません。代わりにプロバイダーのレスキューイメージを起動し、実際のディスクをマウントして、その中でパスワードを変更します。

lsblk
sudo mount /dev/vda1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt passwd ubuntu
sudo umount -R /mnt

パーティション構成は、このページから /dev/vda1 をコピーせず、lsblk で確認します。root パーティションはサイズが大きいパーティションです。UEFI イメージでは、その隣に小さな EFI パーティションがあります。このパーティションには /etc ディレクトリがありません。

SSH がパスワードを受け付けなくなった場合の対処

まだ利用できるセッションから作業します。セッションが残っていない場合は、コンソールを使用します。

Permission denied, please try again. は、サーバーがパスワード認証を提示したものの、送信したパスワードを拒否したことを示します。一般的な原因は、Caps Lock が有効になっていること、またはパスワード設定時と異なるキーボードレイアウトのコンソールを使用していることです。

Permission denied (publickey). は、サーバーがパスワード認証を提示していないことを示します。そのため、有効な値は PasswordAuthentication no です。この no はメインファイルまたは drop-in に記述されている可能性があるため、両方を確認します。sshd は設定の開始時に /etc/ssh/sshd_config.d/ 配下のファイルを読み込み、各キーワードについて最初に見つけた値を保持します。そのため、drop-in が /etc/ssh/sshd_config を上書きします。Ubuntu 24.04 サーバーを SSH 有効の ISO からインストールした場合は、逆の規則になることもあります。インストーラーが cloud-init の drop-in である 50-cloud-init.conf を残し、PasswordAuthentication yes を設定するため、メインファイルに追加した no は無視されます。有効な値を確認します。

sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

KbdInteractiveAuthentication yes と PasswordAuthentication no が併用されている場合も、キーボードインタラクティブ認証が同じ PAM スタックを実行するため、パスワードは通ります。一方を無効にして他方を有効にしたままにすると、鍵認証のみのように見えるサーバーが入力されたパスワードを受け付け続けます。

同じ行は、鍵認証が拒否された場合にも表示されます。パスワードではなく鍵を提示した場合、サーバーのパスワード設定は、Permission denied (publickey) の背後にある5つの原因の1つにすぎません。ssh -v の出力から、どの原因に該当するかが分かります。

切断メッセージの Too many authentication failures は、接続がサーバーの MaxAuthTries の上限を使い切ったことを示します。デフォルトでは6回です。一般的な原因は、パスワード認証に到達するまでクライアントが複数の鍵を提示したことです。認証方式を1つに限定します。

ssh -o IdentitiesOnly=yes -o PubkeyAuthentication=no deploy@203.0.113.10

1分前まで動作していたポートで Connection refused と表示される場合は、SSH を監視する fail2ban が、認証失敗を繰り返したアドレスを禁止した可能性があります。デフォルトの禁止ルールはパケットを破棄せず拒否するため、タイムアウトせずにすぐ拒否されます。コンソールから sudo fail2ban-client status sshd で禁止されたアドレスを一覧表示し、sudo fail2ban-client set sshd unbanip 203.0.113.10 で自分のアドレスを解除します。

パスワードは通過点であり、鍵認証が最終形です

SSH で使えるパスワードは、インターネット上のすべてのスキャナーが推測できるパスワードです。鍵認証へ移行すれば、推測攻撃を気にする必要がなくなります。鍵ペアを生成し、公開鍵を登録します。その後、別のターミナルから鍵でログインできることを確認してから、ほかの変更を行ってください。SSH 鍵管理の基本では、生成、authorized_keys、パスフレーズについて説明しています。

次にパスワード認証を無効にします。編集したファイルを信頼するのではなく、sudo sshd -T で無効化を確認してください。VPS の SSH を堅牢化するでは、変更する価値のある sshd の設定を詳しく説明しています。新しい VPS の最初の 10 分では、新しいサーバーで実施する順序に沿って説明しています。

その後も、パスワードを 1 つ残してください。鍵のみで接続するサーバーでは、sshd の設定を壊すとプロバイダーのコンソールからしか接続できません。そのコンソールでは、ユーザー名とパスワードが必要です。強力なパスワードを保存しているアカウントがあれば、5 分で修復できるか、再インストールが必要になるかが分かれます。

FAQ

root のパスワードを以前のものが分からない状態で VPS 上で変更するにはどうすればよいですか？

sudo を実行できるユーザーでログインし、sudo passwd root を実行します。sudo による認証がすでに完了しているため、以前のパスワードを求められずに新しいパスワードを設定できます。サーバー上に sudo を実行できるアカウントがない場合は、プロバイダーのコンソールを開き、GRUB の recovery menu で再起動して、root の shell entry を選択します。次に mount -o remount,rw / を実行し、その後 passwd を実行します。root にすでにパスワードが設定されており、紛失したのがそのパスワードである場合、recovery shell でパスワードを求められます。この場合は、プロバイダーの rescue image でディスクを mount し、chroot する方法が残ります。

passwd で「Authentication token manipulation error」と表示されるのはなぜですか？

このメッセージの原因は 2 つあります。一般的な原因は Current password: プロンプトへの回答が正しくないことです。その下の passwd: password unchanged 行により、何も書き込まれていないことを確認できます。もう 1 つは、ファイルシステムに書き込めないことです。recovery mode では / が read-only で mount されているため、この状態になります。mount -o remount,rw / を実行してから、もう一度試してください。

Linux のパスワードを変更すると sudo のパスワードも変わりますか？

はい。sudo 自体にはパスワードがありません。PAM を通じて、SSH と su が使用する同じ /etc/shadow エントリに対して認証するため、アカウントごとにパスワードは 1 つです。そのため、変更後に最初に表示される sudo プロンプトが実際の確認になります。作業中のセッションがまだ利用できる間に sudo -k && sudo -v を実行すると、そのプロンプトを強制的に表示できます。

パスワードを変更すると SSH key や開いているセッションに影響しますか？

パスワードの変更や passwd -l では影響しません。公開鍵認証ではパスワード hash を確認しないため、どちらを実行した後も key は使用できます。chage -d 0 は別です。sshd は key によるログイン後も PAM の account checks を実行し、/etc/shadow のパスワード有効期限フィールドを読み取ります。そのため、期限切れのパスワードがあると、key によるログインでも新しいパスワードを要求され、script 化した SSH コマンドも失敗します。すでに開いているセッションは開いたままです。SSH はログイン時にだけ認証情報を確認するためです。稼働中のセッション内で変わるのは sudo だけです。これは 15 minute の timestamp が期限切れになると、新しいパスワードを 1 回要求します。

次回のログイン時にユーザーへパスワードを変更させるにはどうすればよいですか？

sudo chage -d 0 deploy を実行するか、sudo passwd -e deploy を実行します。どちらも同じ処理を行います。保存されている最終変更日が epoch に移動し、PAM はパスワードを期限切れとして扱います。次回の対話型ログインでは、shell が開始される前に新しいパスワードを設定する必要があります。SSH 経由の script で使用しているアカウントには実行しないでください。その場合、非対話型コマンドは Password change required but no TTY available. で失敗し、実行されません。