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

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

UbuntuでVPS（仮想プライベートサーバー）のrootパスワードを変更するには、sudoを実行できるユーザーとしてSSH（セキュアシェル）セッションを開き、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（pluggable authentication modules）を通じてパスワードを再確認します。デフォルトでは、最後のプロンプトから15分後です。そのため、新しいパスワードが初めて実際に検証されるのは、ログイン時ではなく、次に sudo がパスワードを要求したときです。

最初のセッションを開いたまま、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 を含むファイルシステムに書き込みできません。これは recovery mode では通常の状態です。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にある鍵は引き続き使用できます。公開鍵認証では/etc/shadowを参照しないためです。アカウントを完全に停止するには、アカウント自体を期限切れにします。

sudo usermod --expiredate 1 deploy

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

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

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

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

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

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

sudo sshd -T | grep -i permitrootlogin

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

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

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

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 はすべての Ubuntu LTS リリースで同じように動作しますが、chpasswd -c YESCRYPT は異なります。20.04 の古い shadow パッケージは、その方式名を認識しません。

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

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

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

別のアカウントをテストするには、権限のないシェルから 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 は最終変更日をエポックに設定するため、PAM はパスワードを期限切れとして扱います。次回の対話型ログインでは、シェルを起動する前に現在のパスワードと新しいパスワードの入力を求められます。sudo passwd -e deploy もまったく同じ処理を行います。

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

Password change required but no TTY available.

この行以降は何も実行されず、ジョブにはゼロ以外の終了コードだけが報告されます。

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

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（仮想ネットワークコンピューティング）コンソールまたはシリアルコンソールとして表示されます。このコンソールはネットワークスタックの下にある仮想マシンへ接続するため、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 ファイルシステムが読み取り専用でマウントされるため、これを実行しないと、/etc/shadow に書き込めず、passwd は passwd: Authentication token manipulation error で失敗します。
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はどこかで設定されています。Ubuntu 22.04以降では通常、メインファイルを上書きするdrop-inファイルとして/etc/ssh/sshd_config.d/以下に配置されています。実際に適用される値を確認します。

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

KbdInteractiveAuthentication yesがPasswordAuthentication noと併用されている場合、パスワードは引き続き使用できます。keyboard-interactive方式は同じPAMスタックを実行するためです。一方を無効にしてもう一方を有効にしたままにすると、鍵認証のみのように見えるサーバーが入力されたパスワードを受け付け続けます。

切断メッセージ内の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

VPSで古いrootパスワードが分からない場合、どのようにrootパスワードを変更しますか？

sudoを実行できるユーザーでログインし、sudo passwd rootを実行します。sudoによる認証がすでに完了しているため、古いパスワードを要求せずに新しいパスワードを設定できます。サーバー上のどのアカウントでもsudoを実行できない場合は、プロバイダーのコンソールを開き、GRUBのリカバリーメニューで再起動し、rootのシェルエントリを選択して、mount -o remount,rw /を実行し、その後passwdを実行します。rootにすでにパスワードが設定されており、失ったパスワードがそれである場合、リカバリーシェルはそのパスワードを要求します。その場合は、プロバイダーのレスキューイメージでディスクをマウントし、chrootする方法が残されています。

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

このメッセージは2つの原因で表示されます。よくある原因はCurrent password:プロンプトへの回答が正しくないことです。その下のpasswd: password unchanged行で、何も書き込まれていないことを確認できます。もう1つの原因は、ファイルシステムが書き込み不可であることです。リカバリーモードでは/が読み取り専用でマウントされているため、この状態になります。mount -o remount,rw /を実行してから、もう一度試してください。

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

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

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

いいえ。公開鍵認証では/etc/shadowを読み取らないため、パスワード変更後、passwd -l後、chage -d 0後もキーは引き続き使用できます。SSHはログイン時だけ認証情報を確認するため、すでに開いているセッションは維持されます。稼働中のセッションで変わるのはsudoだけです。sudoは、15分のタイムスタンプが期限切れになると、新しいパスワードを1回要求します。

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

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