著者 Ubuntu VPSのrootパスワードを変更する方法
Ubuntu VPSでrootやユーザーのパスワードをpasswd、chpasswd、chageで変更します。SSH接続や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 つ目のセッションを開きます
ここで新しい SSH セッションを開き、接続したままにします。このガイドで発生する問題のほとんどは、認証済みのシェルが 1 つでも残っていれば 2 分で修正できます。最後のシェルを閉じた後は、コンソールに接続しなければならない場合があります。
すでに開いているシェルは、そのシェルが属するアカウントのパスワードを変更、ロック、または期限切れにした後も動作します。SSH はログイン時に認証情報を確認し、その後は再確認しないためです。例外は sudo です。sudo はタイムスタンプの有効期限が切れると、PAM（pluggable authentication modules）を使用してパスワードを再確認します。デフォルトでは、最後にプロンプトを表示してから 15 分後です。そのため、新しいパスワードが初めて実際に検証されるのはログイン時ではなく、次に sudo がパスワードを要求したときです。
最初のセッションを開いたまま、2 つ目のセッションで新しいパスワードをテストします。
passwd で自分のパスワードを変更する
passwdChanging password for deploy.
Current password:
New password:
Retype new password:
passwd: password updated successfullypasswd: 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 ファイルにより、そのアカウントはパスワードなしで sudo を実行できるためです。
sudo passwd で別のユーザーのパスワードを変更する
sudo passwd deployroot には古いパスワードが求められません。また、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 permitrootloginsshd -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 -eopenssl passwd -6 はエコーなしでパスワードを 2 回入力するよう求め、その後 $6$ で始まる SHA-512 crypt ハッシュを出力します。-e により、chpasswd は 2 番目のフィールドがすでにハッシュ化されていると認識するため、そのまま /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 パッケージは、その方式名を認識しません。これらのハッシュはリリースをまたいでも使用できるため、24.04 のサーバーを 26.04 にアップグレードしても、全員のパスワードをリセットする必要はありません。
パスワードが実際に変更されたことを確認するにはどうしますか？
まずメタデータを確認し、次にログインして実際に検証します。
sudo passwd -S deploydeploy P 08/01/2026 0 99999 7 -12 番目のフィールドは状態です。P は使用可能なパスワード、L はロック済み、NP はパスワードが設定されていないことを示します。日付はパスワードを最後に変更した日なので、今日の日付になっているはずです。その後の数字は、以下で説明する有効期限関連のフィールドです。
実環境で最も安全なテストは、sudo 自体です。sudo -k はキャッシュされたタイムスタンプを破棄し、sudo -v は新しい入力プロンプトを強制します。そこで新しいパスワードが受け付けられれば、PAM がそのパスワードを受け付けたことになり、現在のセッションには何も変更を加えていません。
sudo -k && sudo -v別のアカウントをテストするには、権限のないシェルから su - deploy を実行します。sudo su - deploy は実行しないでください。root にはパスワードが求められないため、テストになりません。誤ったパスワードを入力すると、su: Authentication failure が表示されます。
本当のテストは、現在の作業セッションを開いたまま、ノート PC から新しい 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.この行より後の処理は実行されず、ジョブにはゼロ以外の終了コードだけが報告されます。
パスワード有効期限フィールドの意味
sudo chage -l deployLast 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 の設定やファイアウォールルールの影響を受けません。
- 管理パネルからサーバーを再起動し、コンソールを監視します。
- GRUB メニューを表示します。通常、クラウドイメージでは
GRUB_TIMEOUT=0が設定されています。再起動が始まったら、BIOS ブートではShiftを押し続け、UEFI ブートではEscを繰り返し押します。 Advanced options for Ubuntuを選択し、次に(recovery mode)で終わるエントリを選択して、リカバリーメニューでrootを選択します。- まず
mount -o remount,rw /を実行します。リカバリー環境では root ファイルシステムが読み取り専用でマウントされるため、これを実行しないと、書き込みできず/etc/shadowを原因としてpasswdがpasswd: Authentication token manipulation errorで失敗します。 - 対象のアカウントに対して
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 以降では通常、メインファイルを上書きする /etc/ssh/sshd_config.d/ 配下の drop-in ファイルに設定されています。実効値を確認します。
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.101 分前まで動作していたポートで Connection refused が表示される場合、通常は SSH を監視する fail2ban が、認証失敗を繰り返した接続元アドレスを ban しています。デフォルトの ban ルールはパケットを破棄するのではなく拒否するため、タイムアウトせずにすぐ拒否されます。コンソールから sudo fail2ban-client status sshd を実行すると ban 中のアドレスが表示され、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 の 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 自体にはパスワードがありません。PAM を通じて、SSH と su が使用する同じ /etc/shadow エントリで認証するため、アカウントごとにパスワードは 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. で失敗し、実行されません。