著者 Ubuntu VPSのrootパスワードを変更する方法
Ubuntu VPSでrootやユーザーのパスワードをpasswd、chpasswd、chageで変更する方法を解説します。SSH接続や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（プラuggable authentication modules）を通じてパスワードを再確認します。デフォルトでは、最後にプロンプトが表示されてから 15 分後です。そのため、新しいパスワードが初めて実際に検証されるのは、ログイン時ではなく、次に sudo がパスワードを要求したときです。
1 つ目のセッションを開いたまま、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 file により、そのアカウントはパスワードなしで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 は使用しないでください。これはロックではなく空のパスワードを設定します。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 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この方法は動作しますが、平文のパスワードが shell の履歴と 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別のアカウントをテストするには、権限のない 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.この行より後の処理は実行されず、ジョブにはゼロ以外の終了コードだけが報告されます。
パスワードの有効期限関連フィールドの意味
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（virtual network computing）またはシリアルコンソールとして表示されます。このコンソールはネットワークスタックの下にある仮想マシンへ接続するため、sshd の設定やファイアウォールルールの影響を受けません。
- 管理パネルからサーバーを再起動し、コンソールを監視します。
- GRUB メニューを表示します。クラウドイメージでは通常
GRUB_TIMEOUT=0が設定されているため、BIOS ブートでは再起動が始まったらShiftを押し続けます。UEFI ブートでは、再起動が始まったらEscを繰り返し押します。 Advanced options for Ubuntuを選択し、続いて(recovery mode)で終わるエントリを選択し、最後にリカバリーメニューでrootを選択します。- 最初に
mount -o remount,rw /を実行します。リカバリー環境では root ファイルシステムが読み取り専用でマウントされるため、これを実行しないと、書き込みできずpasswd: Authentication token manipulation errorという理由でpasswdが失敗します。/etc/shadowには書き込めません。 - 対象のアカウントに対して
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 スタックを実行するためです。一方だけを無効にして他方を有効にすると、鍵認証のみのように見えるサーバーでも、入力したパスワードを受け付ける状態になります。
この同じ行は、鍵認証が拒否された場合にも表示されます。パスワードではなく鍵を提示していた場合、サーバーのパスワード設定は、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.101分前まで接続できていたポートで 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 パスワードが分からない場合、新しいパスワードに変更するにはどうすればよいですか？
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 keys や現在開いているセッションに影響しますか？
いいえ。Public key authentication は/etc/shadowを読み取らないため、パスワードを変更した後も、passwd -lの後も、chage -d 0の後も keys は使用できます。すでに開いているセッションも、SSH が認証情報を確認するのはログイン時だけなので、そのまま維持されます。実行中のセッション内で変わるのはsudoだけです。sudoは15分の timestamp の有効期限が切れると、新しいパスワードを1回求めます。
次回のログイン時にユーザーへパスワード変更を強制するにはどうすればよいですか？
sudo chage -d 0 deployを実行するか、同じ処理を行うsudo passwd -e deployを実行します。保存されている最終変更日が epoch に移動し、PAM はパスワードを期限切れとして扱います。次回の interactive login では、shell が開始する前に新しいパスワードを設定する必要があります。SSH 経由で scripts が使用するアカウントには実行しないでください。その場合、non-interactive command はPassword change required but no TTY available.で失敗し、実行されません。