Jak zweryfikować sumę kontrolną pliku w Linux

Weryfikacja pobranego pliku za pomocą sumy kontrolnej w dwie minuty

Aby zweryfikować pobrany plik za pomocą sumy kontrolnej, należy wygenerować skrót otrzymanego pliku i porównać go z wartością udostępnioną przez wydawcę. Narzędzie sha256sum wykonuje obie części tego zadania: samodzielnie wyświetla skrót, a z flagą -c odczytuje listę skrótów i wskazuje, które pliki są zgodne. Niniejszy przewodnik przeprowadza przez cały proces na utworzonym pliku, a następnie celowo go uszkadza, aby umożliwić obserwację błędu w praktyce.

Należy pamiętać o jednej zasadzie przez cały czas trwania procesu. Suma kontrolna informuje jedynie, czy posiadane bajty są tymi samymi, które wygenerowały dany skrót; nie dostarcza ona żadnych informacji o autorze pliku. To drugie pytanie wymaga użycia podpisu cyfrowego oraz zaufanego klucza. Ostatnia część przewodnika dokładnie wyjaśnia, gdzie przebiega granica między tymi dwoma mechanizmami.

Utworzenie pliku do ćwiczeń

Należy pracować w katalogu tymczasowym, aby operacje nie wpływały na pozostałe elementy systemu. Wszystkie poniższe polecenia pochodzą z pakietu GNU coreutils, który stanowi podstawowy zestaw narzędzi dostępny na każdym serwerze Ubuntu lub Debian, zatem instalacja dodatkowego oprogramowania nie jest wymagana.

mkdir -p ~/checksum-demo
cd ~/checksum-demo
printf 'the payload of a totally ordinary download\n' > payload.txt
sha256sum payload.txt

Wynikiem jest jedna linia: 64 znaki szesnastkowe, dwie spacje, a następnie nazwa pliku. Te 64 znaki stanowią skrót (digest) pliku. Po ponownym uruchomieniu polecenia linia pozostaje identyczna, ponieważ haszowanie jest deterministyczne: te same dane wejściowe zawsze generują ten sam wynik. Zmiana choćby jednego znaku w pliku i ponowne uruchomienie polecenia powoduje, że skrót nie zmienia się tylko nieznacznie. Wygląda on zupełnie inaczej, ponieważ zmiana jednego bitu wejściowego powoduje zmianę około połowy bitów wyjściowych. Ta właściwość sprawia, że 64-znakowy ciąg może pełnić funkcję użytecznego odpowiednika obrazu o rozmiarze 4 GB.

Zapisywanie pliku SHA256SUMS i jego weryfikacja

Suma kontrolna wyświetlona na ekranie jest bezużyteczna po upływie doby. Należy zapisać ją do pliku w formacie, w jakim generuje go sha256sum, aby narzędzie mogło później odczytać zawartość.

sha256sum payload.txt > SHA256SUMS
cat SHA256SUMS
sha256sum -c SHA256SUMS

sha256sum -c odczytuje każdą linię listy, oblicza skrót pliku wskazanego w tej linii i porównuje go z zapisaną wartością. Poprawne wykonanie operacji skutkuje wyświetleniem jednej linii dla każdego pliku:

payload.txt: OK

Należy również sprawdzić kod wyjścia, ponieważ skrypty odczytują ten parametr, a nie tekst wyjściowy. echo $? wyświetla 0 po pomyślnym zakończeniu weryfikacji. Nazwa SHA256SUMS jest raczej konwencją niż sztywną regułą, jednak dystrybucje oraz większość stron z wydaniami oprogramowania ją stosują. Warto używać tej samej nazwy, aby inni użytkownicy wiedzieli, co zawiera plik bez konieczności jego otwierania.

Zmiana jednego bajta powoduje niepowodzenie weryfikacji

Teraz celowo uszkodź plik. Poniższe polecenie zapisuje pojedynczy bajt pod offsetem 5, nie zmieniając reszty zawartości, dzięki czemu plik zachowuje swoją długość oraz nazwę.

printf 'X' | dd of=payload.txt bs=1 seek=5 conv=notrunc status=none
cat payload.txt
sha256sum -c SHA256SUMS

conv=notrunc to kluczowa flaga: bez niej dd przycina plik w miejscu, w którym kończy zapis, co prowadziłoby do testowania znacznie bardziej oczywistego rodzaju uszkodzenia. Weryfikacja wyświetla teraz komunikat:

payload.txt: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

echo $? wypisuje 1. FAILED oznacza, że plik został odczytany, a jego suma kontrolna nie zgadza się z tą zapisaną na liście. Przywróć oryginalne bajty i potwierdź, że weryfikacja ponownie zwraca OK:

printf 'the payload of a totally ordinary download\n' > payload.txt
sha256sum -c SHA256SUMS

To cała procedura. Różnica jednego bajta w dowolnym miejscu pliku skutkuje komunikatem FAILED. Pobieranie przerwane przez zerwane połączenie, serwer lustrzany udostępniający wczorajszą wersję kompilacji, proxy modyfikujące plik w trakcie przesyłania lub dysk zwracający uszkodzony blok: wszystkie te przypadki kończą się tym samym komunikatem.

Gdy lista zawiera plik, którego nie pobrano

Plik SHA256SUMS pochodzący z oficjalnego źródła dystrybucji zawiera listę wszystkich obrazów udostępnianych przez projekt, z których pobrano tylko jeden. Poniżej przedstawiono odtworzenie tej sytuacji.

printf 'a second file\n' > notes.txt
sha256sum payload.txt notes.txt > SHA256SUMS.all
rm notes.txt
sha256sum -c SHA256SUMS.all

payload.txt: OK
sha256sum: notes.txt: No such file or directory
notes.txt: FAILED open or read
sha256sum: WARNING: 1 listed file could not be read

FAILED open or read to inny błąd niż FAILED, a ich mylenie powoduje stratę czasu. FAILED oznacza, że suma kontrolna bajtów jest nieprawidłowa. FAILED open or read oznacza, że sha256sum w ogóle nie otrzymał pliku, więc porównanie nie zostało wykonane. W przypadku rzeczywistego pobierania najczęstszą przyczyną jest niewłaściwy katalog roboczy, ponieważ nazwy w pliku listy są relatywne względem miejsca uruchomienia polecenia. Należy przejść do katalogu zawierającego plik i uruchomić polecenie ponownie. Aby sprawdzić tylko posiadane pliki, należy wywołać polecenie w następujący sposób:

sha256sum --ignore-missing -c SHA256SUMS.all

Polecenie to wyświetla payload.txt: OK i kończy działanie z kodem 0. Jeśli w katalogu nie znajduje się żaden z plików wymienionych na liście, --ignore-missing nie kończy się cichym sukcesem dla zera plików. Zgłasza ono, że no file was verified i kończy działanie z kodem błędu, co jest pożądanym zachowaniem, ponieważ weryfikacja, która niczego nie sprawdziła, stanowi awarię, której można by nie zauważyć.

Wklejanie opublikowanego skrótu bez weryfikacji wzrokowej

Porównywanie wzrokowe 64 znaków szesnastkowych to moment, w którym ten nawyk zawodzi. Użytkownicy sprawdzają pierwsze cztery i ostatnie cztery znaki, uznając je za zgodne, a dokładnie na takie porównanie liczy zdeterminowany atakujący. Należy pozwolić, aby porównania dokonało narzędzie. Przypisz EXPECTED do skrótu skopiowanego od wydawcy, używając EXPECTED=, a następnie wklejonej wartości, po czym zbuduj pojedynczą linię, której oczekuje -c:

printf '%s  %s\n' "$EXPECTED" payload.txt > payload.sha256
cat payload.sha256
sha256sum -c payload.sha256

Pomiędzy skrótem a nazwą pliku znajdują się dwie spacje, dlatego ciąg formatujący zawiera dwie. Jest to format, w którym zapisuje sha256sum i który odczytuje -c. Plik zawierający wyłącznie skrót nie jest linią sumy kontrolnej, więc weryfikacja odrzuci cały plik z komunikatem no properly formatted checksum lines found, zamiast zgadywać, o który plik chodziło. Niektóre projekty publikują sumy w formacie BSD, używając SHA256 (payload.txt) = przed skrótem. GNU coreutils zapisuje ten format za pomocą sha256sum --tag payload.txt i odczytuje go za pomocą -c, więc oba formaty są poprawne do zapisu.

Jeśli weryfikacja zachowuje się nietypowo, przejrzyj listę za pomocą cat -A SHA256SUMS, co oznaczy koniec każdej linii symbolem $ i wyświetli znaki, których inaczej nie można zobaczyć. Linia kończąca się na ^M$ zawiera znak powrotu karetki (carriage return) dodany przez edytor z systemu Windows. GNU sha256sum ignoruje ten końcowy znak i nadal wyświetla OK, więc lista z CRLF nie jest przyczyną niepowodzenia weryfikacji, chociaż narzędzia spoza coreutils są pod tym względem mniej wyrozumiałe. Znormalizuj przechowywaną kopię za pomocą tr -d '\r' < SHA256SUMS > SHA256SUMS.clean.

Co potwierdza suma kontrolna, a czego nie?

Suma kontrolna potwierdza jedną rzecz: bajty znajdujące się na dysku są tymi samymi bajtami, które wygenerowały opublikowany skrót. W pełni zabezpiecza to przed przypadkowym uszkodzeniem danych. Chroni również przed niedbałym atakującym, który podmienił plik na serwerze lustrzanym, ale nie miał dostępu do strony publikującej skrót.

Suma kontrolna nie potwierdza autorstwa. Skrót jest faktem dotyczącym bajtów, a nie osób. Jeśli jedna strona udostępnia zarówno plik, jak i skrót, to każdy, kto może zmienić jeden z nich, może zmienić również drugi. W takim przypadku wiersz OK oznacza jedynie, że serwer lustrzany jest spójny sam ze sobą. Oto zasada, dzięki której sprawdzanie sum kontrolnych ma sens: pobierz skrót z innego źródła niż plik. Na przykład: pobierz skrót z oficjalnej domeny projektu przez TLS (transport layer security), podczas gdy obraz pobrano z serwera lustrzanego lub sieci torrent. Wtedy atakujący musi przejąć kontrolę nad dwoma miejscami zamiast jednego.

Algorytm również ma znaczenie. SHA-256 (secure hash algorithm, 256-bit output) nie posiada znanych kolizji według stanu na sierpień 2026, dlatego jest stosowany przez wydawców. MD5 (message digest 5) oraz SHA-1 nie są już bezpieczne: dwa różne pliki o tym samym skrócie MD5 można wygenerować od 2004 roku, a kolizję SHA-1 z wybranym prefiksem opublikowano w 2020 roku. Plik MD5SUMS nadal pozwala wykryć niekompletne pobieranie, ponieważ przypadkowa korupcja danych nie jest celowo spreparowaną kolizją. Nie powstrzyma to jednak nikogo, kto próbuje wprowadzić w błąd. Gdy projekt publikuje oba rodzaje sum, należy wybrać wiersz SHA-256.

Gdy podpisy przejmują kontrolę

Podpis wypełnia lukę, którą pozostawia sam skrót. Wydawca podpisuje plik ze skrótami kluczem prywatnym, a użytkownik weryfikuje go kluczem publicznym: gpg --verify SHA256SUMS.asc SHA256SUMS. Jeśli weryfikacja przebiegnie pomyślnie, oznacza to, że lista skrótów pochodzi od posiadacza tego klucza. Następnie sha256sum -c SHA256SUMS wiąże plik na dysku z listą, a łańcuch zaufania prowadzi od klucza aż do samych bajtów.

Słaby punkt przesuwa się na klucz. Pobranie klucza z tej samej strony, z której pobrano plik, oddaje obie części w ręce atakującego. GnuPG otwarcie o tym informuje, a pierwsza weryfikacja wyświetla Good signature wraz z WARNING: This key is not certified with a trusted signature!. Good signature oznacza, że matematyka się zgadza. Nie oznacza to jednak, że klucz należy do projektu, o którym myślisz. Pobierz odcisk klucza (fingerprint) z drugiego źródła, na przykład z dokumentacji projektu w innej domenie lub z pakietu dystrybucyjnego, który już zawiera ten klucz, i porównaj pełny odcisk zamiast ostatnich ośmiu znaków. Wymaga to takiej samej dbałości, jak w przypadku klucza prywatnego SSH, z tego samego powodu: klucz jest decyzją o zaufaniu, a wszystko, co znajduje się poniżej w łańcuchu, dziedziczy to zaufanie.

Powtarzalne kompilacje (reproducible builds) rozwijają tę ideę o krok dalej. Opublikowany skrót nadal wiąże użytkownika z plikiem binarnym zbudowanym na jednej maszynie. Gdy kompilacja projektu jest powtarzalna, każdy może skompilować to samo źródło i uzyskać wynik identyczny co do bajta. Dzięki temu niezależni twórcy mogą potwierdzić opublikowany skrót, zamiast polegać na zapewnieniach jednego serwera. Ma to coraz większe znaczenie, ponieważ coraz więcej kodu trafia do systemów poprzez zautomatyzowane potoki (pipelines) i poprawki generowane maszynowo. Decyzja o tym, co jest akceptowane w procesie budowania, jest kwestią polityki, a polityki open source dotyczące kodu wspomaganego przez AI pracują nad tym samym łańcuchem dostaw z drugiej strony.

Menedżer pakietów wykonuje to zadanie automatycznie

W systemach Debian i Ubuntu narzędzie apt uruchamia ten łańcuch weryfikacji przy każdej instalacji bez dodatkowych poleceń. Indeks pakietów zawiera sumę kontrolną SHA-256 dla każdego pliku .deb. Plik Release zawiera sumy kontrolne tych plików indeksu, a InRelease przechowuje podpis pliku Release, weryfikowany za pomocą kluczy znajdujących się w /usr/share/keyrings oraz /etc/apt/trusted.gpg.d. W przypadku przerwania łańcucha, apt zgłasza błąd: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY, gdy brakuje klucza zewnętrznego repozytorium, lub Hash Sum mismatch, gdy pobrany indeks nie zgadza się z podpisanym plikiem Release. Zazwyczaj oznacza to, że serwer proxy dostarczył nieaktualny plik z pamięci podręcznej lub pobieranie nastąpiło w trakcie synchronizacji mirrora.

Jest to standard, do którego należy się odnosić, gdy strona domowa projektu zaleca przesyłanie skryptu z curl bezpośrednio do powłoki. W takim przypadku żadne mechanizmy nie weryfikują bajtów, a użytkownik ich nie widzi. Serwer może również zwrócić inną treść skryptowi, a inną przeglądarce, co uniemożliwia późniejszą inspekcję kodu. Należy pobrać plik za pomocą curl -fsSL <url> -o install.sh, obliczyć jego sumę kontrolną, przejrzeć zawartość przy użyciu less i dopiero wtedy uruchomić skrypt. Ten nawyk zajmuje około dwudziestu sekund i warto go wdrożyć już na etapie konfiguracji nowego serwera VPS w pierwszych dziesięciu minutach, zanim zainstalowane zostanie jakiekolwiek inne oprogramowanie.

Utrzymywanie listy sum kontrolnych dla oprogramowania instalowanego ręcznie

Pakiety instalowane przez apt są śledzone. Plik binarny skopiowany do /usr/local/bin nie jest objęty tym mechanizmem i żaden proces w systemie go nie monitoruje. Lista sum kontrolnych pozwala przekształcić taki plik w obiekt, który można weryfikować na żądanie:

printf 'a second file\n' > notes.txt
sha256sum *.txt > inventory.sha256
sha256sum -c --quiet inventory.sha256

--quiet nie wyświetla żadnych informacji, gdy wszystkie pliki są zgodne, a w przypadku niezgodności wypisuje tylko błędne linie. Brak danych wyjściowych oznacza sukces, co potwierdza echo $? za pomocą 0. Jest to format odpowiedni do wykorzystania w zadaniach zaplanowanych. --status działa jeszcze bardziej restrykcyjnie, nie wypisując niczego i zwracając jedynie kod wyjścia. Zastosowanie tego samego schematu do rzeczywistych plików za pomocą sha256sum /usr/local/bin/* > ~/local-bin.sha256 pozwala utworzyć linię bazową. Ścieżki są przechowywane na liście dokładnie w takiej formie, w jakiej zostały wpisane, dlatego użycie ścieżek bezwzględnych umożliwia uruchomienie weryfikacji z dowolnego katalogu.

Należy mieć świadomość wartości takiej linii bazowej. Pozwala ona wykryć zmianę pliku. Nie wykryje jednak atakującego, który uzyskał już uprawnienia root, ponieważ może on zmodyfikować inventory.sha256 równie łatwo, jak zmodyfikował plik binarny. Aby lista zachowała wiarygodność, należy przechowywać ją poza maszyną, co stanowi część szerszego zagadnienia dotyczącego poziomu zaufania do VPS oraz tego, kto jeszcze ma dostęp do fizycznego nośnika danych.

FAQ

Czy zgodna suma kontrolna oznacza, że pobrany plik jest bezpieczny?

Nie. Oznacza to jedynie, że bajty pliku zgadzają się ze skrótem, z którym zostały porównane. Jeśli atakujący kontroluje stronę, na której opublikowano skrót, opublikuje on skrót własnego pliku, a weryfikacja zwróci OK. Zgodność jest jedynie potwierdzeniem spójności danych. Gwarancja bezpieczeństwa wymaga podpisu zweryfikowanego kluczem uzyskanym z innego źródła; dopiero wtedy skrót przejmuje to zaufanie.

Dlaczego sha256sum -c zwraca FAILED open or read?

Ponieważ plik nie został odczytany. Wiersz powyżej wskazuje No such file or directory wraz z nazwą pliku, którego szukano. Nazwy w pliku SHA256SUMS są relatywne względem katalogu, w którym uruchomiono polecenie, dlatego należy przejść do katalogu z pobranym plikiem i uruchomić je ponownie. Jeśli lista zawiera pliki, których nie pobrano, należy dodać flagę --ignore-missing. Zwykłe FAILED bez open or read oznacza sytuację odwrotną: plik został odczytany, ale jego skrót nie zgadza się z oczekiwanym.

Czy MD5 wystarcza do weryfikacji pobranego pliku?

W przypadku przypadkowych uszkodzeń – tak. Przerwany transfer lub uszkodzony blok dysku nie wygenerują przypadkowo pasującego skrótu MD5. W przypadku ataku – nie. Dwa różne pliki o tym samym skrócie MD5 można wygenerować od 2004 roku, a SHA-1 uległo atakom kolizyjnym w 2020 roku. Należy wybierać SHA-256, jeśli projekt udostępnia oba skróty, a projekty oferujące wyłącznie MD5 traktować jako sygnał przestarzałego procesu wydawniczego.

Jaka jest różnica między sha256sum -c a gpg --verify?

sha256sum -c potwierdza, że plik zgadza się ze skrótem. gpg --verify potwierdza, że plik ze skrótami został podpisany przez posiadacza konkretnego klucza prywatnego. Odpowiadają one na różne pytania, dlatego należy wykonać obie operacje, jeśli projekt je udostępnia. Podpis czyni listę skrótów wiarygodną, a lista skrótów czyni pobrany plik wiarygodnym.

Jak sprawdzić plik względem skrótu podanego na stronie internetowej?

Nie należy porównywać znaków „na oko”. Należy zapisać skrót i nazwę pliku w jednym wierszu, oddzielając je dwiema spacjami, a następnie uruchomić sha256sum -c dla tego pliku i odczytać OK lub FAILED. Przygotowanie wiersza za pomocą printf '%s %s\n' pozwala uniknąć błędów formatowania, przez które sha256sum odrzuca plik z komunikatem no properly formatted checksum lines found.