Weryfikacja sumy kontrolnej pliku w systemie 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 przykładzie utworzonego pliku, a następnie celowo go uszkadza, aby umożliwić obserwację błędu w praktyce.

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

Utworzenie pliku do ćwiczeń

Należy pracować w katalogu tymczasowym, aby nie wpływać 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 nie ma potrzeby instalowania dodatkowego oprogramowania.

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

Otrzymasz jedną linię: 64 znaki szesnastkowe, dwie spacje, a następnie nazwę pliku. Te 64 znaki to skrót (digest) pliku. Uruchom polecenie ponownie, a linia będzie identyczna, ponieważ haszowanie jest deterministyczne: te same dane wejściowe zawsze dają ten sam wynik. Zmień jeden znak w pliku i uruchom polecenie ponownie – skrót nie zmieni się tylko nieznacznie. Będzie wyglądał 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 znaków może służyć jako użyteczny odpowiednik 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 generowanym przez 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 oba skróty. 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, ignorując tekst. echo $? wyświetla 0 po poprawnym zakończeniu operacji. Nazwa SHA256SUMS jest raczej konwencją niż sztywną zasadą, jednak dystrybucje oraz większość stron z wydaniami oprogramowania ją stosują. Warto używać tej 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 pozostałej 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 obcina plik w miejscu, w którym kończy zapis, co prowadziłoby do testowania znacznie bardziej oczywistego rodzaju uszkodzenia. Weryfikacja wyświetla teraz:

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

echo $? wypisuje 1. FAILED oznacza, że plik został odczytany, a jego skrót nie zgadza się z tym zawartym 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

Na tym polega cały nawyk. Jeden bajt różnicy w dowolnym miejscu pliku skutkuje FAILED. Pobieranie przerwane przez zerwane połączenie, serwer lustrzany udostępniający wczorajszą wersję, proxy, które zmodyfikowało plik w trakcie przesyłania, czy dysk, który zwrócił uszkodzony blok: wszystkie te przypadki kończą się tym samym komunikatem.

Gdy lista zawiera plik, którego nie pobrano

Prawidłowy plik SHA256SUMS z dystrybucji zawiera listę wszystkich obrazów, które projekt udostępnia, a użytkownik pobrał tylko jeden z nich. Należy odtworzyć tę sytuację tutaj.

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 bajty są nieprawidłowe. 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 typową przyczyną jest katalog roboczy, ponieważ nazwy w liście 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 użyć następującej składni:

sha256sum --ignore-missing -c SHA256SUMS.all

Polecenie to wyświetla payload.txt: OK i kończy działanie z kodem 0. Jeśli żadna z wymienionych nazw nie jest obecna, --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 niezerowym kodem, co jest pożądanym zachowaniem, ponieważ weryfikacja, która niczego nie sprawdziła, jest błędem, którego można by nie zauważyć.

Wklejanie opublikowanego skrótu bez weryfikacji wzrokowej

Porównywanie wzrokowe 64 znaków szesnastkowych jest miejscem, w którym ten nawyk zawodzi. Użytkownicy sprawdzają pierwsze cztery i ostatnie cztery znaki, uznając je za zgodne, a jest to dokładnie ten sposób porównania, na który liczy zdeterminowany atakujący. Należy pozwolić narzędziu na wykonanie porównania. 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 odrzuca 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 stylu BSD, używając SHA256 (payload.txt) = przed skrótem. GNU coreutils zapisuje tę formę za pomocą sha256sum --tag payload.txt i odczytuje ją za pomocą -c, więc oba formaty są poprawne do zapisu.

Jeśli weryfikacja zachowuje się nietypowo, przejrzyj listę za pomocą cat -A SHA256SUMS, które oznacza koniec każdej linii za pomocą $ i pokazuje znaki, których inaczej nie można zobaczyć. Linia kończąca się na ^M$ zawiera znak powrotu karetki (carriage return) pochodzący z edytora systemu Windows. GNU sha256sum ignoruje ten końcowy znak i nadal wyświetla OK, więc lista z CRLF nie jest przyczyną niepowodzenia weryfikacji, choć narzędzia spoza coreutils są mniej wyrozumiałe w tej kwestii. 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 uzyskał dostępu do strony publikującej skrót.

Suma kontrolna nie potwierdza autorstwa. Skrót jest faktem dotyczącym bajtów, a nie faktem dotyczącym 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, a Twój wiersz OK oznacza jedynie, że serwer lustrzany jest spójny sam ze sobą. Oto zasada, która sprawia, że weryfikacja sum kontrolnych ma sens: pobierz skrót z innego źródła niż plik. Na przykład: pobierz obraz z serwera lustrzanego lub sieci torrent, a skrót z oficjalnej domeny projektu zabezpieczonej przez TLS (transport layer security). W ten sposób atakujący musiałby przejąć kontrolę nad dwoma miejscami zamiast jednego. Suma kontrolna nie mówi również nic o tym, co zweryfikowane bajty zrobią po uruchomieniu. Jest to osobne pytanie, które warto zadać w odniesieniu do wszystkiego, co wykonuje kod w Twoim imieniu, od skryptu instalacyjnego po wtyczkę dsh działającą z uprawnieniami Twojego agenta.

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 było wygenerować już w 2004 roku, a kolizję SHA-1 z wybranym prefiksem opublikowano w 2020 roku. Plik MD5SUMS nadal pozwala wykryć przerwane pobieranie, ponieważ przypadkowe uszkodzenie danych nie jest celowo spreparowaną kolizją. Nie powstrzyma to jednak nikogo, kto próbuje wprowadzić Cię w błąd. Gdy projekt publikuje oba rodzaje sum, zawsze wybieraj wiersz SHA-256.

Gdzie wkraczają podpisy

Podpis wypełnia lukę, którą pozostawia 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, przekazuje obie części ataku w ręce napastnika. GnuPG informuje o tym wprost, 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 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 klucz prywatny 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 przez jedną maszynę. 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 kompilacji, jest kwestią polityki, a polityki open source dla kodu wspomaganego przez AI zajmują się tym samym łańcuchem dostaw z drugiej strony.

Menedżer pakietów wykonuje to zadanie automatycznie

W systemach Debian i Ubuntu apt uruchamia ten łańcuch 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 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 lub pobieranie nastąpiło w trakcie synchronizacji serwera lustrzanego.

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. Żaden mechanizm nie weryfikuje pobranych bajtów, a użytkownik nie ma do nich wglądu. Serwer może 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ść poleceniem less i dopiero wtedy uruchomić skrypt. Ten nawyk zajmuje około dwudziestu sekund i warto go wdrożyć na nowo zakupionym serwerze VPS w ciągu pierwszych dziesięciu minut, zanim zainstalowane zostanie jakiekolwiek inne oprogramowanie.

Prowadzenie listy sum kontrolnych dla ręcznie instalowanych plików

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 na weryfikację takich plików 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 użycia w zaplanowanych zadaniach. --status działa jeszcze bardziej dyskretnie, nie wyświetlając niczego i zwracając jedynie kod wyjścia. Wskazanie tego samego wzorca dla rzeczywistych plików za pomocą sha256sum /usr/local/bin/* > ~/local-bin.sha256 pozwala utworzyć linię bazową. Ścieżki są zapisywane na liście dokładnie w takiej formie, w jakiej zostały wpisane, dlatego użycie ścieżek bezwzględnych umożliwia uruchomienie sprawdzania 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 swoją wiarygodność, należy przechowywać ją poza serwerem. Jest to element 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 są zgodne 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 dziedziczy 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ć --ignore-missing. Zwykłe FAILED bez open or read oznacza sytuację odwrotną: plik został odczytany, ale jego skrót nie jest zgodny.

Czy MD5 jest wystarczające do weryfikacji pobranego pliku?

W przypadku przypadkowych uszkodzeń – tak. Przerwany transfer lub uszkodzony blok dysku nie wygenerują przypadkowo zgodnego 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 stało się podatne na kolizje typu chosen-prefix w 2020 roku. Należy korzystać z sumy SHA-256, jeśli projekt udostępnia obie, 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 jest zgodny 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 wzrokowo. Należy zapisać skrót oraz nazwę pliku w jednym wierszu, oddzielając je dwiema spacjami, a następnie uruchomić sha256sum -c dla tego pliku i sprawdzić 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.