Jak zmienić hasło root na VPS z Ubuntu

Jak zmienić hasło root na VPS z Ubuntu

Aby zmienić hasło root na VPS (wirtualnym serwerze prywatnym) z systemem Ubuntu, należy otworzyć sesję SSH (secure shell) jako użytkownik, który może uruchamiać sudo, a następnie uruchomić sudo passwd root. Polecenie poprosi dwukrotnie o nowe hasło. Nie poprosi o stare hasło, ponieważ sudo potwierdziło już tożsamość użytkownika. Aby zamiast tego zmienić własne hasło logowania, należy uruchomić passwd bez argumentów. W tym przypadku najpierw zostanie wyświetlona prośba o podanie bieżącego hasła.

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

To cała operacja. Poniżej opisano problemy, które występują najczęściej: sprawdzenie, czy nowe hasło działa, zanim zostanie utracona sesja umożliwiająca naprawę problemu, ustawianie haseł w skrypcie, celowe wygaszenie hasła oraz odzyskanie dostępu, gdy hasło zostało już utracone.

Otwórz drugą sesję przed zmianą hasła

Otwórz teraz drugą sesję SSH i pozostaw ją połączoną. Prawie każdą awarię opisaną w tym przewodniku można naprawić w ciągu dwóch minut, dopóki działa jedna uwierzytelniona powłoka. Po jej zamknięciu konieczne może być użycie konsoli.

Już otwarta powłoka nadal działa po zmianie, zablokowaniu lub wygaśnięciu konta, do którego należy, ponieważ SSH sprawdza dane uwierzytelniające podczas logowania i nie sprawdza ich ponownie. Wyjątkiem jest sudo. Po wygaśnięciu znacznika czasu ponownie sprawdza hasło za pośrednictwem PAM (modułów uwierzytelniania podłączanych), domyślnie 15 minut po ostatnim monicie. Dlatego nowe hasło zostanie po raz pierwszy rzeczywiście sprawdzone przy następnym żądaniu hasła przez sudo, a nie podczas logowania.

Przetestuj nowe hasło w drugiej sesji, pozostawiając pierwszą otwartą.

Zmiana własnego hasła za pomocą passwd

passwd

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

passwd: password updated successfully to jedyny komunikat oznaczający, że skrót w /etc/shadow został zastąpiony. Każdy inny komunikat oznacza, że stare hasło pozostało bez zmian.

Występują tu dwa błędy. passwd: Authentication token manipulation error, a następnie passwd: password unchanged oznaczają, że wpisane bieżące hasło jest nieprawidłowe albo system plików zawierający /etc/shadow nie pozwala na zapis. W trybie odzyskiwania jest to stan normalny. You must choose a longer password. pochodzi z pam_unix w /etc/pam.d/common-password. Ten mechanizm sprawdza długość i podobieństwo haseł zwykłych użytkowników.

Na większości obrazów VPS konto domyślne (ubuntu lub inna nazwa używana przez dostawcę) nie ma hasła, a jedynie klucz SSH. passwd nie ma bieżącego hasła do weryfikacji, więc nie może przejść pierwszego monitu. Zamiast tego należy użyć sudo passwd $USER. Działa ono, ponieważ plik dodatkowej konfiguracji sudoers obrazu umożliwia temu kontu uruchomienie sudo bez hasła.

Zmiana hasła innego użytkownika za pomocą sudo passwd

sudo passwd deploy

Root nie jest proszony o podanie starego hasła, a pam_unix pomija kontrole siły hasła stosowane wobec zwykłych użytkowników. Dzięki temu root może ustawić hasło, którego użytkownik nie mógłby ustawić samodzielnie.

Zablokowanie hasła jest oddzielną czynnością. sudo passwd -l deploy umieszcza ! przed zapisanym skrótem, więc żadne hasło nie będzie do niego pasować. sudo passwd -u deploy usuwa ten znak. Stan można odczytać za pomocą sudo passwd -S deploy.

Zablokowanie hasła nie uniemożliwia temu użytkownikowi logowania. Każdy klucz zapisany w jego ~/.ssh/authorized_keys nadal działa, ponieważ uwierzytelnianie za pomocą klucza publicznego nigdy nie odczytuje /etc/shadow. Aby całkowicie zablokować konto, należy wygasić samo konto:

sudo usermod --expiredate 1 deploy

Powoduje to ustawienie daty wygaśnięcia konta na dzień w 1970 roku. W rezultacie sshd odrzuca logowanie niezależnie od użytych danych uwierzytelniających. Cofnięcie tej zmiany wykonuje się za pomocą sudo usermod --expiredate '' deploy.

Należy unikać passwd -d. Ustawia ono puste hasło zamiast zablokowanego hasła. W starszej wersji, która nadal zawiera nullok w stosie PAM, puste hasło może wykorzystać każdy.

Czy konto root na VPS potrzebuje hasła?

W systemie Ubuntu konto root jest domyślnie zablokowane. /etc/shadow zawiera ! zamiast skrótu, a sudo passwd -S root wyświetla wiersz rozpoczynający się od root L. Do czasu ustawienia hasła nie można zalogować się jako root za pomocą hasła. Z tego powodu obraz systemu udostępnia użytkownika z uprawnieniami sudo. Należy korzystać z kont użytkowników z minimalnymi uprawnieniami na VPS, a nie z konta root.

Ustawienie hasła root zapewnia jedną konkretną możliwość: dostęp za pośrednictwem konsoli dostawcy. Konsola ta łączy się z maszyną wirtualną poniżej warstwy sieciowej. Dlatego nadal działa, gdy konfiguracja sshd jest nieprawidłowa lub reguła zapory sieciowej zawiera błąd. Ma to również wadę. Powłoka root w menu odzyskiwania GRUB żąda hasła root, gdy dla tego konta ustawiono hasło. Narzędzie używane do resetowania zapomnianego hasła zostaje więc zabezpieczone tym samym hasłem.

Ustawienie hasła root nie umożliwia logowania jako root przez SSH. Ubuntu domyślnie używa PermitRootLogin prohibit-password, co oznacza logowanie wyłącznie za pomocą kluczy. Należy sprawdzić, jakie ustawienia są faktycznie używane przez serwer:

sudo sshd -T | grep -i permitrootlogin

sshd -T wyświetla efektywną konfigurację po rozwiązaniu każdego wiersza Include. Jest to więc jedyna wiarygodna odpowiedź, gdy /etc/ssh/sshd_config.d/ zawiera pliki konfiguracyjne typu drop-in.

Ustawianie hasła ze skryptu za pomocą chpasswd

passwd odczytuje dane z terminala i nie można sterować nim ze skryptu. chpasswd odczytuje pary user:password ze standardowego wejścia, po jednej w każdym wierszu.

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

To działa, ale powoduje zapisanie hasła w postaci jawnej w historii powłoki i w dziennikach CI (ciągłej integracji). Najpierw utwórz jego skrót:

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

openssl passwd -6 dwukrotnie żąda podania hasła bez wyświetlania znaków, a następnie wyświetla skrót SHA-512 crypt rozpoczynający się od $6$. -e informuje chpasswd, że drugie pole zawiera już skrót, dlatego jest on kopiowany do /etc/shadow bez zmian. Skrót można bezpiecznie przechowywać w repozytorium lub zmiennej CI, a hasło w postaci jawnej nigdy nie opuszcza komputera, na którym zostało wpisane.

Ubuntu 24.04 tworzy skróty nowych haseł za pomocą yescrypt ($y$), gdy ustawia je passwd, natomiast openssl passwd -6 używa SHA-512. Oba formaty są weryfikowane podczas logowania, ponieważ libxcrypt odczytuje oba. Można ich używać jednocześnie. openssl passwd -6 działa tak samo w każdej wersji Ubuntu LTS, w przeciwieństwie do chpasswd -c YESCRYPT: starszy pakiet shadow w wersji 20.04 nie zna tej nazwy metody.

Jak sprawdzić, czy hasło rzeczywiście zostało zmienione?

Najpierw należy sprawdzić metadane, a następnie potwierdzić zmianę podczas logowania.

sudo passwd -S deploy

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

Drugie pole określa stan: P oznacza używane hasło, L — zablokowane hasło, a NP — brak hasła. Data wskazuje czas ostatniej zmiany hasła, dlatego powinna odpowiadać bieżącej dacie. Kolejne liczby to pola kontroli ważności hasła opisane poniżej.

Najbezpieczniejszym testem wykonywanym na działającym systemie jest użycie samego sudo. sudo -k usuwa zapisany znacznik czasu, a sudo -v wymusza wyświetlenie nowego monitu. Jeśli nowe hasło zostanie tam zaakceptowane, PAM je zaakceptował, a stan sesji nie uległ zmianie.

sudo -k && sudo -v

Aby przetestować inne konto, należy uruchomić su - deploy z powłoki bez uprawnień uprzywilejowanych. Nie należy uruchamiać sudo su - deploy, ponieważ root nigdy nie jest proszony o hasło, więc taki test niczego nie potwierdza. Nieprawidłowe hasło powoduje wyświetlenie su: Authentication failure.

Rzeczywistym testem jest nowe logowanie SSH z laptopa przy nadal otwartej działającej sesji:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). oznacza tutaj, że serwer nie zaoferował uwierzytelniania za pomocą hasła, dlatego żadna zmiana hasła nie umożliwi logowania. Permission denied, please try again. oznacza, że serwer je zaoferował, ale odrzucił wprowadzone hasło.

Wymuszenie zmiany hasła przy następnym logowaniu za pomocą chage

sudo chage -d 0 deploy

-d 0 ustawia datę ostatniej zmiany na epokę, dlatego PAM traktuje hasło jako wygasłe. Przy następnym logowaniu interaktywnym najpierw wymagane jest bieżące hasło, a następnie nowe hasło, zanim zostanie udostępniona powłoka. sudo passwd -e deploy wykonuje dokładnie tę samą czynność.

Należy używać tego wyłącznie w przypadku kont, na które użytkownik loguje się interaktywnie za pomocą hasła. Wygasłe hasło wpływa również na logowanie za pomocą klucza, ponieważ sshd wykonuje etap account PAM nawet wtedy, gdy uwierzytelnienie nastąpiło za pomocą klucza. Skryptowane ssh deploy@203.0.113.10 'systemctl restart app' kończy się wtedy błędem i zatrzymuje:

Password change required but no TTY available.

Żadne polecenia znajdujące się po tym wierszu nie zostają wykonane, a zadanie zgłasza wyłącznie kod zakończenia różny od zera.

Znaczenie pól starzenia hasła

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

Te liczby są polami od 4 do 8 w wierszu tego użytkownika w /etc/shadow. Minimalna liczba dni (chage -m) określa, jak długo użytkownik musi czekać przed ponowną zmianą hasła. Zapobiega to natychmiastowemu powrotowi do starego hasła po wymuszonej zmianie. Maksymalna liczba dni (chage -M) określa, jak długo hasło pozostaje ważne. Liczba dni ostrzeżenia (chage -W) określa moment rozpoczęcia wyświetlania ostrzeżeń podczas logowania. Liczba dni nieaktywności (chage -I) określa okres karencji po wygaśnięciu hasła, zanim przestanie ono być w ogóle akceptowane. Wygaśnięcie konta (chage -E) oznacza nieprzekraczalną datę i jest niezależne od hasła.

sudo chage -M 90 -W 14 deploy

Należy ustawiać tę wartość tylko wtedy, gdy wymaga tego zasada. NIST (amerykański National Institute of Standards and Technology) od 2017 roku odradza rutynowe wygaszanie haseł, ponieważ skłania ono użytkowników do tworzenia przewidywalnych wariantów jednego hasła. Zamiast tego zaleca wymuszenie zmiany po uzyskaniu dowodów naruszenia bezpieczeństwa. Długie, unikatowe hasło przechowywane w menedżerze haseł oraz SSH oparte na kluczach zapewniają lepsze bezpieczeństwo niż cykl 90 dni.

Co zrobić po utracie hasła root

Jeśli dowolne konto na serwerze może uruchomić sudo, nie ma czego odzyskiwać: sudo passwd root ustawia nowe hasło. Trudniejszy przypadek występuje wtedy, gdy nie działa żadne logowanie.

Wszystkie poniższe czynności wymagają konsoli dostawcy, która w większości paneli jest dostępna jako konsola VNC (virtual network computing) lub konsola szeregowa. Łączy się ona z maszyną wirtualną poniżej warstwy stosu sieciowego, dlatego ustawienia sshd i reguły zapory sieciowej nie mają na nią wpływu.

1. Uruchom ponownie serwer z poziomu panelu i obserwuj konsolę.
2. Otwórz menu GRUB. Obrazy chmurowe zwykle ustawiają GRUB_TIMEOUT=0, dlatego podczas uruchamiania w trybie BIOS przytrzymaj Shift, a podczas uruchamiania w trybie UEFI naciskaj wielokrotnie Esc, gdy tylko rozpocznie się ponowne uruchamianie.
3. Wybierz Advanced options for Ubuntu, następnie wpis kończący się na (recovery mode), a potem root w menu odzyskiwania.
4. Najpierw uruchom mount -o remount,rw /. System odzyskiwania montuje główny system plików tylko do odczytu, dlatego bez tego polecenia passwd kończy się błędem passwd: Authentication token manipulation error, ponieważ nie może zapisać /etc/shadow.
5. Uruchom passwd ubuntu dla potrzebnego konta, a następnie uruchom serwer ponownie z poziomu panelu.

Jeśli root ma już hasło i jest to hasło, które utracono, powłoka odzyskiwania poprosi o jego podanie i ta metoda nie zadziała. Należy zamiast tego uruchomić obraz ratunkowy dostawcy, zamontować właściwy dysk i zmienić hasło w jego systemie.

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

Układ partycji należy odczytać z lsblk, a nie kopiować /dev/vda1 z tej strony. Partycja główna jest największą partycją. W obrazie UEFI znajduje się obok małej partycji EFI, która nie zawiera w ogóle katalogu /etc.

Co zrobić, gdy SSH przestaje akceptować hasło

Pracuj z sesji, która nadal jest dostępna. Jeśli nie ma już żadnej sesji, użyj konsoli.

Permission denied, please try again. oznacza, że serwer zaoferował uwierzytelnianie hasłem, ale odrzucił przesłane hasło. Typowymi przyczynami są włączony Caps Lock lub układ klawiatury konsoli różniący się od układu używanego podczas ustawiania hasła.

Permission denied (publickey). oznacza, że serwer w ogóle nie zaoferował uwierzytelniania hasłem. PasswordAuthentication no jest ustawione w jednym z plików konfiguracyjnych. W Ubuntu 22.04 i nowszych zwykle znajduje się w pliku dodatkowej konfiguracji w katalogu /etc/ssh/sshd_config.d/, który nadpisuje plik główny. Odczytaj efektywne wartości:

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

KbdInteractiveAuthentication yes wraz z PasswordAuthentication no nadal umożliwia użycie hasła, ponieważ metoda keyboard-interactive korzysta z tego samego stosu PAM. Wyłączenie jednej metody przy pozostawieniu drugiej włączonej powoduje, że serwer pozornie ograniczony do kluczy nadal akceptuje hasła wpisywane z klawiatury.

Too many authentication failures w komunikacie o rozłączeniu oznacza, że klient zaoferował kilka kluczy, zanim przeszedł do hasła, a serwer osiągnął MaxAuthTries, którego domyślna wartość wynosi 6. Wymuś użycie jednej metody:

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

Connection refused na porcie, który działał jeszcze minutę temu, zwykle oznacza, że fail2ban monitorujący SSH zablokował Twój adres po wielokrotnych nieudanych próbach. Jego domyślna reguła blokady odrzuca pakiet zamiast go porzucać, dlatego odmowa pojawia się szybko, a nie po przekroczeniu limitu czasu. Z konsoli polecenie sudo fail2ban-client status sshd wyświetla zablokowane adresy, a sudo fail2ban-client set sshd unbanip 203.0.113.10 usuwa Twój adres z listy.

Hasła to etap przejściowy, klucze to stan docelowy

Hasło działające przez SSH jest hasłem, którego może próbować każdy skaner w Internecie. Należy przejść na uwierzytelnianie za pomocą klucza. Wtedy zgadywanie hasła przestaje mieć znaczenie. Należy wygenerować parę kluczy, zainstalować klucz publiczny i potwierdzić w drugim terminalu, że klucz umożliwia logowanie, zanim zostaną wprowadzone inne zmiany. Podstawy zarządzania kluczami SSH obejmują generowanie kluczy, authorized_keys oraz hasła zabezpieczające.

Następnie należy wyłączyć uwierzytelnianie za pomocą hasła i potwierdzić to poleceniem sudo sshd -T, zamiast ufać zmodyfikowanemu plikowi. Wzmacnianie zabezpieczeń SSH na VPS omawia pozostałe ustawienia sshd, które warto zmienić, a Pierwsze dziesięć minut na nowym VPS przedstawia kolejność wykonywania tych czynności na nowym serwerze.

Po wykonaniu tych czynności należy zachować jedno hasło. Serwer, na którym logowanie odbywa się wyłącznie za pomocą klucza, a konfiguracja sshd jest uszkodzona, jest dostępny tylko przez konsolę dostawcy. Ta konsola wymaga podania nazwy użytkownika i hasła. Konto z silnym, zapisanym hasłem decyduje o tym, czy naprawa potrwa pięć minut, czy konieczna będzie ponowna instalacja.

FAQ

Jak zmienić hasło root na serwerze VPS, jeśli nie jest znane stare hasło?

Należy zalogować się jako użytkownik, który może uruchamiać sudo, a następnie uruchomić sudo passwd root. Polecenie ustawia nowe hasło bez żądania starego, ponieważ sudo przeprowadził już uwierzytelnianie. Jeśli żadne konto na serwerze nie może uruchamiać sudo, należy otworzyć konsolę dostawcy, uruchomić ponownie system do menu odzyskiwania GRUB, wybrać wpis powłoki root, uruchomić mount -o remount,rw /, a następnie passwd. Jeśli konto root ma już hasło i jest to hasło, które zostało utracone, powłoka odzyskiwania zażąda jego podania. Pozostaje wtedy użycie obrazu ratunkowego dostawcy, zamontowanie dysku i wykonanie operacji chroot.

Dlaczego passwd wyświetla komunikat „Authentication token manipulation error”?

Ten komunikat może mieć 2 przyczyny. Najczęstszą jest nieprawidłowa odpowiedź w monicie Current password:. Wiersz passwd: password unchanged poniżej potwierdza, że nie zapisano żadnych zmian. Drugą przyczyną jest system plików, na którym nie można zapisywać. Taka sytuacja występuje w trybie odzyskiwania, ponieważ / jest tam zamontowany tylko do odczytu. Należy uruchomić mount -o remount,rw / i spróbować ponownie.

Czy zmiana hasła systemu Linux zmienia również hasło sudo?

Tak. sudo nie ma własnego hasła. Uwierzytelnia użytkownika za pośrednictwem PAM na podstawie tego samego wpisu /etc/shadow, którego używają SSH i su. Dlatego dla każdego konta istnieje jedno hasło. Z tego samego powodu pierwszy monit sudo po zmianie hasła jest właściwym testem. Należy uruchomić sudo -k && sudo -v, aby wymusić wyświetlenie tego monitu podczas aktywnej sesji.

Czy zmiana hasła unieważni klucze SSH lub otwarte sesje?

Nie. Uwierzytelnianie za pomocą klucza publicznego nie odczytuje /etc/shadow, dlatego klucze nadal działają po zmianie hasła, po passwd -l oraz po chage -d 0. Już otwarte sesje pozostają aktywne, ponieważ SSH sprawdza dane uwierzytelniające tylko podczas logowania. Jedyną zmianą w aktywnej sesji jest działanie sudo, które zażąda nowego hasła po wygaśnięciu 15-minutowego znacznika czasu.

Jak wymusić zmianę hasła użytkownika przy następnym logowaniu?

Należy uruchomić sudo chage -d 0 deploy lub sudo passwd -e deploy, które wykonuje tę samą operację. Zapisana data ostatniej zmiany zostaje ustawiona na epokę. PAM uznaje hasło za wygasłe, a podczas następnego logowania interaktywnego wymagane jest ustawienie nowego hasła przed uruchomieniem powłoki. Nie należy stosować tego wobec konta używanego przez skrypty za pośrednictwem SSH. Polecenie nieinteraktywne zakończy się wtedy błędem Password change required but no TTY available. i nie zostanie wykonane.