Jak zmienić hasło root na Ubuntu przez SSH

Jak zmienić hasło użytkownika root na serwerze VPS z systemem Ubuntu

Aby zmienić hasło użytkownika root na serwerze VPS (virtual private server) z systemem Ubuntu, należy otworzyć sesję SSH (secure shell) jako użytkownik posiadający uprawnienia do uruchamiania polecenia sudo, a następnie wykonać sudo passwd root. System poprosi o dwukrotne podanie nowego hasła i nie będzie wymagał podania starego, ponieważ sudo już potwierdziło tożsamość użytkownika. Aby zmienić własne hasło logowania, należy wykonać polecenie passwd bez argumentów; w tym przypadku system najpierw poprosi 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 procedura. Poniżej opisano etapy, na których często dochodzi do błędów: weryfikację działania nowego hasła przed zamknięciem aktywnej sesji, która pozwala na naprawę konfiguracji, ustawianie haseł za pomocą skryptów, celowe wymuszanie wygaśnięcia hasła oraz odzyskiwanie dostępu w przypadku utraty hasła.

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

Otwórz teraz drugą sesję SSH i pozostaw ją aktywną. Niemal każdą awarię opisaną w tym przewodniku można naprawić w dwie minuty, dopóki działa choć jedna uwierzytelniona powłoka; w przeciwnym razie konieczna będzie wizyta przy konsoli.

Otwarta powłoka działa nadal po zmianie, zablokowaniu lub wygaśnięciu konta, do którego należy, ponieważ SSH weryfikuje poświadczenia tylko podczas logowania. Wyjątkiem jest sudo. Narzędzie to ponownie sprawdza hasło przez PAM (pluggable authentication modules) po wygaśnięciu znacznika czasu, domyślnie 15 minut od ostatniego wywołania. Nowe hasło zostanie więc faktycznie przetestowane dopiero wtedy, gdy sudo poprosi o nie ponownie, a nie w momencie logowania.

Przetestuj nowe hasło w drugiej sesji, podczas gdy pierwsza pozostaje otwarta.

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 wynik oznacza, że stare hasło pozostało aktywne.

W tym miejscu występują dwie awarie. passwd: Authentication token manipulation error, po którym następuje passwd: password unchanged, oznacza, że wpisane bieżące hasło było błędne lub system plików zawierający /etc/shadow jest tylko do odczytu, co jest stanem typowym w trybie odzyskiwania. You must choose a longer password. wynika z pam_unix w /etc/pam.d/common-password, który stosuje sprawdzanie długości i podobieństwa haseł dla zwykłych użytkowników.

W większości obrazów VPS konto domyślne (ubuntu lub nazwa dostarczona przez dostawcę) nie posiada hasła, a jedynie klucz SSH. passwd nie ma bieżącego hasła do weryfikacji, więc nie może przejść przez pierwszy monit. Należy użyć sudo passwd $USER, co działa, ponieważ plik konfiguracyjny sudoers w obrazie pozwala temu kontu na uruchomienie sudo bez podawania hasła.

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

sudo passwd deploy

Użytkownik root nie jest pytany o stare hasło, a pam_unix pomija testy siły hasła stosowane wobec zwykłych użytkowników, dzięki czemu root może ustawić hasło, którego użytkownik nie mógłby ustawić samodzielnie.

Blokowanie jest osobną czynnością. sudo passwd -l deploy wstawia ! przed zapisanym hashem, co sprawia, że żadne hasło do niego nie pasuje. sudo passwd -u deploy usuwa ten znak. Stan konta można sprawdzić za pomocą sudo passwd -S deploy.

Zablokowanie hasła nie uniemożliwia użytkownikowi logowania. Każdy klucz w jego ~/.ssh/authorized_keys nadal działa, ponieważ uwierzytelnianie kluczem publicznym nigdy nie odczytuje /etc/shadow. Aby całkowicie zablokować konto, należy ustawić datę wygaśnięcia samego konta:

sudo usermod --expiredate 1 deploy

Ustawia to datę wygaśnięcia konta na rok 1970, więc sshd odrzuci logowanie niezależnie od przedstawionych poświadczeń. Cofnięcie tej operacji odbywa się za pomocą sudo usermod --expiredate '' deploy.

Należy unikać passwd -d. Ustawia ono puste hasło zamiast blokady, a w starszych wydaniach, które nadal posiadają nullok w stosie PAM, puste hasło może zostać wykorzystane przez dowolną osobę.

Czy konto root wymaga hasła na serwerze VPS?

Dystrybucja Ubuntu jest dostarczana z zablokowanym kontem root. Plik /etc/shadow zawiera ! zamiast skrótu hasła, a polecenie sudo passwd -S root wyświetla linię zaczynającą się od root L. Logowanie na konto root przy użyciu hasła jest niemożliwe do momentu jego ustawienia, dlatego obraz systemu udostępnia użytkownika z uprawnieniami sudo. Praca w oparciu o konta użytkowników z minimalnymi uprawnieniami na VPS, zamiast bezpośrednio na koncie root, jest zalecanym standardem bezpieczeństwa.

Ustawienie hasła dla konta root zapewnia jedną konkretną korzyść: możliwość dostępu przez konsolę dostawcy. Konsola ta łączy się z maszyną wirtualną z pominięciem stosu sieciowego, dzięki czemu działa nawet w przypadku błędnej konfiguracji sshd lub nieprawidłowych reguł firewalla. Rozwiązanie to wiąże się jednak z pewnym kosztem. Powłoka root w menu odzyskiwania GRUB wymaga podania hasła root, jeśli zostało ono ustawione, co oznacza, że narzędzie służące do resetowania zapomnianego hasła staje się zabezpieczone tym samym hasłem.

Ustawienie hasła dla konta root nie umożliwia logowania przez SSH. Ubuntu domyślnie stosuje PermitRootLogin prohibit-password, co oznacza wymóg użycia kluczy. Należy sprawdzić, jakie ustawienia faktycznie obowiązują na serwerze:

sudo sshd -T | grep -i permitrootlogin

Polecenie sshd -T wyświetla efektywną konfigurację po przetworzeniu wszystkich dyrektyw Include, dlatego jest to jedyne wiarygodne źródło informacji w sytuacji, gdy /etc/ssh/sshd_config.d/ zawiera dodatkowe pliki konfiguracyjne.

Ustawianie hasła ze skryptu za pomocą chpasswd

passwd odczytuje dane z terminala i nie może być sterowane ze skryptu. chpasswd odczytuje pary user:password ze standardowego wejścia, po jednej w każdej linii.

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

To rozwiązanie działa, ale umieszcza hasło w postaci jawnej w historii powłoki oraz w logach CI (ciągłej integracji). Zamiast tego należy najpierw wygenerować skrót:

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

openssl passwd -6 prosi o dwukrotne podanie hasła bez wyświetlania znaków, a następnie wypisuje skrót SHA-512 crypt zaczynający się od $6$. -e informuje chpasswd, że drugie pole jest już zahaszowane, więc zostaje ono skopiowane do /etc/shadow w niezmienionej formie. Skrót jest bezpieczny do przechowywania w repozytorium lub zmiennej CI, a hasło w postaci jawnej nigdy nie opuszcza maszyny, na której zostało wpisane.

Ubuntu 24.04 haszuje nowe hasła przy użyciu yescrypt ($y$), gdy passwd je ustawia, podczas gdy openssl passwd -6 generuje SHA-512. Oba formaty są weryfikowane przy logowaniu, ponieważ libxcrypt obsługuje oba standardy. Mieszanie ich jest dopuszczalne, a openssl passwd -6 zachowuje się tak samo w każdym wydaniu Ubuntu LTS, czego nie można powiedzieć o chpasswd -c YESCRYPT: starszy pakiet shadow w wersji 20.04 nie rozpoznaje tej nazwy metody. Skróty te przetrwają również aktualizację systemu, więc przeniesienie serwera z 24.04 na 26.04 nie wymusza resetowania haseł użytkowników.

Jak sprawdzić, czy hasło faktycznie zostało zmienione?

Zacznij od metadanych, a następnie potwierdź zmianę poprzez logowanie.

sudo passwd -S deploy

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

Drugie pole oznacza stan: P dla hasła aktywnego, L dla zablokowanego, NP dla braku hasła. Data wskazuje moment ostatniej zmiany hasła, więc powinna odpowiadać dniu dzisiejszemu. Liczby po niej to parametry starzenia hasła, opisane poniżej.

Najbezpieczniejszym testem na żywo jest samo sudo. Polecenie sudo -k odrzuca zapisany znacznik czasu, a sudo -v wymusza wyświetlenie nowego monitu. Jeśli nowe hasło zostanie zaakceptowane, oznacza to, że moduł PAM je przyjął, a bieżąca sesja pozostaje bez zmian.

sudo -k && sudo -v

Aby przetestować inne konto, uruchom su - deploy z nieuprzywilejowanej powłoki. Nie uruchamiaj sudo su - deploy, ponieważ użytkownik root nigdy nie jest pytany o hasło, więc taki test niczego nie dowodzi. Wprowadzenie błędnego hasła spowoduje wyświetlenie komunikatu su: Authentication failure.

Właściwym testem jest nowe logowanie SSH z laptopa, przy zachowaniu otwartej bieżącej sesji:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Komunikat Permission denied (publickey). w tym miejscu oznacza, że serwer nie oferuje uwierzytelniania hasłem, więc żadna zmiana hasła nie umożliwi dostępu. Permission denied, please try again. oznacza, że metoda była oferowana, ale wpisane dane zostały odrzucone.

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

sudo chage -d 0 deploy

-d 0 ustawia datę ostatniej zmiany hasła na epokę, co powoduje, że PAM traktuje hasło jako przeterminowane. Przy następnym logowaniu interaktywnym system poprosi o podanie bieżącego hasła, a następnie o ustawienie nowego, zanim udostępni powłokę. sudo passwd -e deploy wykonuje dokładnie to samo działanie.

Należy stosować to rozwiązanie wyłącznie dla kont, które logują się interaktywnie przy użyciu hasła. Przeterminowane hasło wpływa również na logowanie oparte na kluczach, ponieważ sshd wykonuje etap weryfikacji konta PAM nawet wtedy, gdy uwierzytelnienie nastąpiło za pomocą klucza. Zautomatyzowany skrypt ssh deploy@203.0.113.10 'systemctl restart app' kończy się wówczas niepowodzeniem i przerywa działanie:

Password change required but no TTY available.

Po tej linii nie są wykonywane żadne dalsze operacje, a zadanie zwraca jedynie niezerowy kod wyjścia.

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 to pola od 4 do 8 w wierszu danego użytkownika w pliku /etc/shadow. Minimalna liczba dni (chage -m) określa, jak długo użytkownik musi odczekać przed ponowną zmianą hasła; zapobiega to natychmiastowemu powrotowi do starego hasła po wymuszonej zmianie. Maksymalna liczba dni (chage -M) określa okres ważności hasła. Liczba dni ostrzeżenia (chage -W) wskazuje, kiedy podczas logowania zacznie pojawiać się komunikat ostrzegawczy. Liczba dni nieaktywności (chage -I) to okres karencji po wygaśnięciu hasła, po którym przestaje ono być akceptowane. Data wygaśnięcia konta (chage -E) to sztywny termin, niezależny od ważności samego hasła.

sudo chage -M 90 -W 14 deploy

Ustawiaj te parametry tylko wtedy, gdy wymaga tego polityka bezpieczeństwa. NIST (amerykański National Institute of Standards and Technology) od 2017 roku odradza rutynowe wymuszanie wygasania haseł, ponieważ skłania to użytkowników do tworzenia przewidywalnych wariantów tego samego hasła. Instytut zaleca wymuszanie zmiany hasła jedynie w przypadku podejrzenia naruszenia bezpieczeństwa. Długie, unikalne hasło przechowywane w menedżerze haseł oraz uwierzytelnianie kluczem SSH są skuteczniejsze niż cykliczna zmiana co 90 dni.

Co zrobić w przypadku utraty hasła użytkownika root

Jeśli jakiekolwiek konto na serwerze posiada uprawnienia do uruchomienia sudo, nie ma czego odzyskiwać: sudo passwd root ustawia nowe hasło. Trudniejsza sytuacja występuje, gdy żaden login nie działa.

Wszystkie poniższe kroki wymagają użycia konsoli dostawcy, dostępnej w większości paneli jako VNC (virtual network computing) lub konsola szeregowa. Łączy się ona z maszyną wirtualną z pominięciem stosu sieciowego, więc ustawienia sshd oraz reguły firewalla nie mają na nią wpływu.

1. Zrestartuj serwer z poziomu panelu i obserwuj konsolę.
2. Wywołaj menu GRUB. Obrazy chmurowe zazwyczaj mają ustawione GRUB_TIMEOUT=0, dlatego przytrzymaj Shift podczas bootowania BIOS lub naciskaj wielokrotnie Esc przy bootowaniu UEFI, zaraz po rozpoczęciu restartu.
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 /. Tryb odzyskiwania montuje system plików root w trybie tylko do odczytu, więc bez tego kroku passwd zakończy się błędem passwd: Authentication token manipulation error z powodu braku możliwości zapisu w /etc/shadow.
5. Uruchom passwd ubuntu dla wybranego konta, a następnie zrestartuj serwer z poziomu panelu.

Jeśli użytkownik root posiada już hasło i jest to właśnie to hasło, które zostało utracone, powłoka odzyskiwania poprosi o jego podanie, co uniemożliwi dalsze działania. W takim przypadku należy uruchomić obraz ratunkowy dostawcy, zamontować właściwy dysk i zmienić hasło bezpośrednio w jego systemie plików.

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

Odczytaj układ partycji za pomocą lsblk zamiast kopiować /dev/vda1 z tej strony. Partycja root jest tą większą. W obrazach UEFI znajduje się ona obok małej partycji EFI, która w ogóle nie zawiera katalogu /etc.

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

Należy pracować z sesji, która jest nadal aktywna. Jeśli nie ma żadnej aktywnej sesji, należy użyć konsoli.

Permission denied, please try again. oznacza, że serwer oferował uwierzytelnianie hasłem, ale odrzucił przesłane dane. Typowe przyczyny to włączony Caps Lock lub układ klawiatury w konsoli różniący się od tego, który był używany podczas ustawiania hasła.

Permission denied (publickey). oznacza, że serwer w ogóle nie oferował uwierzytelniania hasłem. Opcja PasswordAuthentication no jest ustawiona w pliku konfiguracyjnym; w systemie Ubuntu 22.04 i nowszych zazwyczaj znajduje się ona w pliku typu drop-in w katalogu /etc/ssh/sshd_config.d/, który nadpisuje plik główny. Należy odczytać efektywne wartości:

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

KbdInteractiveAuthentication yes wraz z PasswordAuthentication no nadal pozwala na logowanie hasłem, ponieważ metoda keyboard-interactive korzysta z tego samego stosu PAM. Wyłączenie jednej opcji przy pozostawieniu drugiej sprawia, że serwer, który wydaje się obsługiwać tylko klucze, nadal akceptuje wpisywane hasła.

Ten sam komunikat pojawia się również w przypadku odrzucenia klucza. Jeśli używany był klucz, a nie hasło, ustawienie hasła na serwerze jest tylko jedną z pięciu przyczyn błędu Permission denied (publickey), a dane wyjściowe ssh -v wskazują, która z nich występuje.

Too many authentication failures w komunikacie o rozłączeniu oznacza, że klient oferował kilka kluczy przed próbą użycia hasła, a serwer osiągnął limit MaxAuthTries, który domyślnie wynosi 6. Należy wymusić użycie jednej metody:

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

Connection refused na porcie, który działał chwilę wcześniej, zazwyczaj oznacza, że fail2ban monitorujący SSH zablokował adres IP po wielokrotnych nieudanych próbach. Domyślna reguła blokowania odrzuca pakiet zamiast go ignorować, dlatego odmowa połączenia następuje natychmiast, zamiast kończyć się przekroczeniem czasu oczekiwania. Z poziomu konsoli polecenie sudo fail2ban-client status sshd wyświetla listę zablokowanych adresów, a sudo fail2ban-client set sshd unbanip 203.0.113.10 usuwa blokadę dla danego adresu.

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

Hasło działające przez SSH jest hasłem, które każdy skaner w Internecie może próbować odgadnąć. Przejście na uwierzytelnianie kluczem sprawia, że zgadywanie przestaje mieć znaczenie. Wygeneruj parę kluczy, zainstaluj część publiczną i potwierdź, że klucz pozwala na zalogowanie się z drugiego terminala, zanim wprowadzisz jakiekolwiek inne zmiany. Podstawy zarządzania kluczami SSH omawiają generowanie, authorized_keys oraz hasła zabezpieczające klucze.

Następnie wyłącz uwierzytelnianie hasłem i potwierdź to za pomocą sudo sshd -T, zamiast polegać wyłącznie na edytowanym pliku. Zabezpieczanie SSH na VPS przeprowadza przez pozostałe ustawienia sshd, które warto zmienić, a pierwsze dziesięć minut na nowym VPS porządkuje te czynności w kolejności zalecanej dla świeżego serwera.

Zachowaj jedno hasło po wykonaniu tych kroków. Serwer dostępny tylko przez klucze z błędną konfiguracją sshd jest osiągalny wyłącznie przez konsolę dostawcy, a ta konsola wymaga nazwy użytkownika i hasła. Konto z silnym hasłem, które przechowujesz w bezpiecznym miejscu, stanowi różnicę między pięciominutową naprawą a koniecznością reinstalacji systemu.

FAQ

Jak zmienić hasło root na VPS, jeśli nie znam starego?

Zaloguj się jako użytkownik z uprawnieniami do uruchamiania sudo i wykonaj sudo passwd root. Ustawia to nowe hasło bez pytania o stare, ponieważ sudo już Cię uwierzytelniło. Jeśli żadne konto w systemie nie może uruchomić sudo, otwórz konsolę dostawcy, zrestartuj serwer do menu odzyskiwania GRUB, wybierz wpis powłoki root, wykonaj mount -o remount,rw /, a następnie passwd. Jeśli root posiada już hasło i to właśnie je utracono, powłoka odzyskiwania poprosi o nie, a jedyną pozostałą drogą jest obraz ratunkowy dostawcy z zamontowanym i chrootowanym dyskiem.

Dlaczego passwd zwraca błąd "Authentication token manipulation error"?

Ten komunikat wywołują dwie przyczyny. Częstszą jest błędna odpowiedź w monicie Current password:, a linia passwd: password unchanged poniżej potwierdza, że nic nie zostało zapisane. Drugą przyczyną jest system plików, do którego nie można dokonywać zapisu, co zdarza się w trybie odzyskiwania, ponieważ / jest tam zamontowany w trybie tylko do odczytu. Wykonaj mount -o remount,rw / i spróbuj ponownie.

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

Tak. sudo nie posiada własnego hasła. Uwierzytelnia użytkownika przez PAM względem tego samego wpisu w /etc/shadow, którego używa SSH oraz su, więc dla każdego konta istnieje tylko jedno hasło. Dlatego też pierwszy monit sudo po zmianie jest właściwym testem. Uruchom sudo -k && sudo -v, aby wymusić ten monit, dopóki aktywna jest działająca sesja.

Czy zmiana hasła spowoduje unieważnienie kluczy SSH lub otwartych sesji?

Nie. Uwierzytelnianie kluczem publicznym nigdy nie odczytuje /etc/shadow, więc klucze działają nadal po zmianie hasła, po passwd -l oraz po chage -d 0. Otwarte sesje pozostają aktywne, ponieważ SSH sprawdza poświadczenia tylko w momencie logowania. Jedyną rzeczą, która zmienia się w aktywnej sesji, jest sudo, który poprosi o nowe hasło po wygaśnięciu 15-minutowego znacznika czasu.

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

Uruchom sudo chage -d 0 deploy lub sudo passwd -e deploy, które wykonują to samo zadanie. Przechowywana data ostatniej zmiany zostaje przesunięta do epoki, PAM traktuje hasło jako wygasłe, a kolejne logowanie interaktywne wymaga ustawienia nowego hasła przed uruchomieniem powłoki. Nie należy stosować tego wobec kont używanych przez skrypty przez SSH: polecenie nieinteraktywne zakończy się wówczas błędem Password change required but no TTY available. i nie zostanie wykonane.