Linux download verifiëren met sha256sum

Een download verifiëren met een checksum in twee minuten

Om een download met een checksum te verifiëren, berekent u de hash van het ontvangen bestand en laat u een tool deze hash vergelijken met de hash die de uitgever heeft gepubliceerd. sha256sum voert beide helften van deze taak uit: op zichzelf print het een digest, en met -c leest het een lijst met digests en rapporteert het welke bestanden overeenkomen. Deze handleiding doorloopt de volledige cyclus met een bestand dat u zelf aanmaakt, waarna u het bestand opzettelijk beschadigt om de foutmelding zelf te zien in plaats van erover te lezen.

Houd gedurende het hele proces één zin in gedachten. Een checksum vertelt u of de bytes die u bezit de bytes zijn die de digest hebben geproduceerd, maar het zegt niets over wie ze heeft geproduceerd. Die tweede vraag vereist een handtekening en een sleutel die u vertrouwt. Het laatste deel van deze handleiding laat precies zien waar de grens tussen beide ligt.

Maak een bestand om mee te oefenen

Werk in een tijdelijke map zodat de rest van het systeem onaangetast blijft. Elke onderstaande opdracht is afkomstig uit GNU coreutils, de standaardset met opdrachten die op elke Ubuntu- of Debian-server aanwezig is; er hoeft dus niets geïnstalleerd te worden.

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

U krijgt één regel: 64 hexadecimale tekens, twee spaties, gevolgd door de bestandsnaam. Die 64 tekens vormen de hashwaarde van het bestand. Voer de opdracht opnieuw uit en de regel is identiek, omdat hashing deterministisch is: dezelfde invoer levert altijd dezelfde uitvoer op. Wijzig één teken in het bestand en voer de opdracht opnieuw uit; de hashwaarde verschuift niet slechts een klein beetje. Het resultaat ziet er volledig anders uit, omdat het omklappen van één bit in de invoer ongeveer de helft van de uitvoerbits doet veranderen. Die eigenschap maakt een tekenreeks van 64 tekens een bruikbare vervanger voor een image van 4 GB.

Een SHA256SUMS-bestand opslaan en controleren

Een hash op het scherm is een dag later waardeloos. Schrijf deze naar een bestand in de indeling die sha256sum zelf gebruikt, zodat de tool het later kan inlezen.

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

sha256sum -c leest elke regel van de lijst, berekent de hash van het bestand dat op die regel staat en vergelijkt de twee hashes. Een succesvolle uitvoering toont één regel per bestand:

payload.txt: OK

Controleer ook de exit-status, aangezien een script deze uitleest en de tekst negeert. echo $? geeft 0 weer na een foutloze uitvoering. De naam SHA256SUMS is een conventie in plaats van een regel, maar distributies en de meeste releasepagina's gebruiken deze naam. Gebruik deze daarom ook, zodat de volgende persoon weet wat het bestand bevat zonder het te openen.

Wijzig één byte en zie hoe de controle faalt

Maak het bestand nu opzettelijk kapot. Dit schrijft één byte op offset 5 en laat de rest ongemoeid, waardoor het bestand zijn lengte en naam behoudt.

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

conv=notrunc is de relevante flag: zonder deze flag kapt dd het bestand af op het punt waar het stopt met schrijven, en zou u een veel duidelijker soort schade testen. De controle geeft nu het volgende weer:

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

echo $? print 1. FAILED betekent dat het bestand is gelezen en dat de digest niet overeenkwam met die in de lijst. Plaats de oorspronkelijke bytes terug en bevestig dat de controle weer OK retourneert:

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

Dat is de gehele procedure. Eén byte verschil, waar dan ook in het bestand, resulteert in FAILED. Een download die voortijdig is afgebroken door een verbroken verbinding, een mirror die de build van gisteren aanbiedt, een proxy die het bestand tijdens het transport heeft herschreven, een schijf die een bad block heeft geretourneerd: ze leiden allemaal tot dezelfde melding.

Wanneer de lijst een bestand bevat dat u niet heeft gedownload

Een echt SHA256SUMS-bestand van een distributie bevat elk image dat het project uitbrengt, en u heeft er slechts één van gedownload. Reproduceer die situatie hier.

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 is een andere fout dan FAILED, en het verwarren van beide kost tijd. FAILED betekent dat de bytes onjuist zijn. FAILED open or read betekent dat sha256sum het bestand helemaal niet heeft ontvangen, waardoor er niets is vergeleken. Bij een echte download is de werkmap meestal de oorzaak, omdat de namen in de lijst relatief zijn aan de locatie waar u het commando uitvoert. Ga naar de map met het bestand en voer het commando opnieuw uit. Om alleen te controleren wat u daadwerkelijk heeft, vraagt u het volgende:

sha256sum --ignore-missing -c SHA256SUMS.all

Dit geeft payload.txt: OK weer en sluit af met exitcode 0. Als geen van de vermelde namen aanwezig is, slaagt --ignore-missing niet stilletjes bij nul bestanden. Het meldt dat no file was verified en sluit af met een non-zero exitcode; dit is het gewenste gedrag, omdat een succesmelding die niets heeft gecontroleerd een fout is die u anders nooit zou opmerken.

Plak een gepubliceerde digest zonder deze handmatig te controleren

Het handmatig vergelijken van 64 hexadecimale tekens is waar deze gewoonte echt tekortschiet. Mensen controleren de eerste vier en de laatste vier tekens en concluderen dat het een match is; dit is precies de vergelijking waar een vastberaden aanvaller op rekent. Laat de tool de vergelijking uitvoeren. Stel EXPECTED in op de digest die u van de uitgever heeft gekopieerd, gebruik EXPECTED= gevolgd door de geplakte waarde, en bouw vervolgens de enkele regel die -c verwacht:

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

Er staan twee spaties tussen de digest en de bestandsnaam, en daarom bevat de opmaakreeks er twee. Dit is de vorm die sha256sum schrijft en die -c kan inlezen. Een bestand dat enkel een digest bevat, is geen checksum-regel; daarom wijst de controle het hele bestand af met no properly formatted checksum lines found in plaats van te gokken welk bestand u bedoelde. Sommige projecten publiceren in plaats daarvan de BSD-stijl, SHA256 (payload.txt) = gevolgd door de digest. GNU coreutils schrijft deze vorm met sha256sum --tag payload.txt en leest deze terug met -c, dus beide vormen zijn prima om op te slaan.

Wanneer een controle vreemd gedrag vertoont, bekijk de lijst dan met cat -A SHA256SUMS. Dit markeert het einde van elke regel met $ en toont tekens die u anders niet kunt zien. Een regel die eindigt op ^M$ bevat een carriage return afkomstig van een Windows-editor. GNU sha256sum negeert dit afsluitende teken en print nog steeds OK, dus een CRLF-lijst is niet de oorzaak van een mislukte controle, hoewel tools buiten coreutils hier minder vergevingsgezind in zijn. Normaliseer de kopie die u bewaart met tr -d '\r' < SHA256SUMS > SHA256SUMS.clean.

Wat bewijst een checksum, en wat niet?

Een checksum bewijst één ding: de bytes op uw schijf zijn de bytes die de gepubliceerde digest hebben gegenereerd. Dit dekt accidentele schade volledig af. Het dekt ook een onvoorzichtige aanvaller die het bestand op een download-mirror heeft vervangen, maar niet bij de pagina kon die de digest publiceerde.

Het bewijst niets over het auteurschap. Een digest is een feit over bytes, geen feit over personen. Als één pagina zowel het bestand als de digest serveert, dan kan degene die het één kan wijzigen ook het ander wijzigen, en betekent uw OK-regel alleen dat de mirror met zichzelf in overeenstemming is. Daarom geldt de regel die het uitvoeren van checksums zinvol maakt: haal de digest ergens anders vandaan dan waar u het bestand heeft gehaald. Bijvoorbeeld via het eigen domein van het project over TLS (transport layer security), terwijl de image van een mirror of een torrent kwam. Nu moet een aanvaller twee locaties controleren in plaats van één.

Het algoritme is ook van belang. SHA-256 (secure hash algorithm, 256-bit output) heeft per augustus 2026 geen bekende botsingen, en daarom gebruiken uitgevers dit. MD5 (message digest 5) en SHA-1 voldoen niet meer: twee verschillende bestanden met dezelfde MD5-digest zijn sinds 2004 te construeren, en een 'chosen-prefix' SHA-1-botsing werd in 2020 gepubliceerd. Een MD5SUMS-bestand detecteert nog steeds een afgebroken download, omdat willekeurige corruptie geen doelbewust gecreëerde botsing is. Het kan echter niemand stoppen die u probeert te misleiden. Wanneer een project beide publiceert, gebruik dan de SHA-256-regel.

Waar handtekeningen het overnemen

Een handtekening dicht het gat dat een digest openlaat. De uitgever ondertekent het digest-bestand met een private key, en u controleert dit met de bijbehorende public key: gpg --verify SHA256SUMS.asc SHA256SUMS. Als deze controle slaagt, is de lijst met digests afkomstig van de houder van die key. Vervolgens koppelt sha256sum -c SHA256SUMS het bestand op uw schijf aan de lijst, waardoor de keten loopt van de key tot aan de individuele bytes.

Het zwakke punt verschuift naar de key. Het ophalen van de key vanaf dezelfde pagina als het bestand geeft een aanvaller beide helften in handen. GnuPG is hier transparant over; bij een eerste verificatie wordt Good signature getoond, samen met WARNING: This key is not certified with a trusted signature!. Good signature betekent dat de wiskundige controle klopt. Het betekent niet dat de key daadwerkelijk toebehoort aan het project dat u voor ogen heeft. Haal de fingerprint op via een tweede bron, zoals de documentatie van het project op een ander domein of een distributiepakket waarin de key al is opgenomen, en vergelijk de volledige fingerprint in plaats van alleen de laatste acht tekens. Dit vereist dezelfde zorgvuldigheid als een SSH private key, om dezelfde reden: de key vormt de basis van uw vertrouwensbesluit, en alles wat daarop volgt erft dit vertrouwen.

Reproduceerbare builds tillen dit concept naar een hoger niveau. Een gepubliceerde digest bindt u nog steeds aan een binary die door één machine is gebouwd. Wanneer de build van een project reproduceerbaar is, kan iedereen dezelfde broncode compileren en een byte-identieke output verkrijgen. Onafhankelijke bouwers kunnen zo de gepubliceerde digest bevestigen, in plaats van dat u moet vertrouwen op het woord van één server. Dit wordt elk jaar belangrijker, naarmate meer code via geautomatiseerde pipelines en door machines geschreven patches binnenkomt. Beslissen wat u accepteert in een build is een beleidskwestie, en open source-beleid voor AI-ondersteunde code werkt aan dezelfde supply chain vanuit de andere kant.

Uw pakketbeheerder doet dit al voor u

Op Debian en Ubuntu voert apt deze keten bij elke installatie automatisch uit. De pakketindex bevat een SHA-256-digest voor elk .deb-bestand. Het Release-bestand bevat de digests van die indexbestanden, en InRelease bevat een handtekening over Release, die wordt gecontroleerd aan de hand van de sleutels in /usr/share/keyrings en /etc/apt/trusted.gpg.d. Wanneer de keten wordt verbroken, meldt apt dit: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY wanneer de sleutel van een externe repository ontbreekt, of Hash Sum mismatch wanneer de opgehaalde index niet overeenkomt met het ondertekende Release. Dit betekent meestal dat een caching-proxy een verouderd bestand heeft geserveerd of dat u een mirror tijdens een synchronisatieproces heeft geraadpleegd.

Dat is de standaard waaraan u moet toetsen wanneer de website van een project u vraagt om een script via curl direct naar een shell te pipen. Niets verifieert de bytes en u krijgt ze nooit te zien. De server kan bovendien het ene naar een script sturen en iets anders naar een browser, en u heeft achteraf geen kopie om te inspecteren. Download het bestand met curl -fsSL <url> -o install.sh, bereken de hash, lees het met less en voer het pas daarna uit. Deze gewoonte kost ongeveer twintig seconden en is dezelfde gewoonte die de moeite waard is om te starten op een gloednieuwe VPS in de eerste tien minuten, voordat er iets anders op de server wordt geïnstalleerd.

Houd een lijst met digests bij voor handmatig geïnstalleerde software

Pakketten die via apt zijn geïnstalleerd, worden bijgehouden. Een binary die u naar /usr/local/bin heeft gekopieerd, wordt niet bijgehouden en er is geen systeemproces dat deze controleert. Een digest-lijst verandert dit in iets dat u op verzoek kunt verifiëren:

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

--quiet geeft geen uitvoer als elk bestand overeenkomt en toont alleen de regels die niet overeenkomen als er wijzigingen zijn; stilte betekent dus dat de controle is geslaagd en echo $? bevestigt dit met 0. Dit is de vorm die u in een geplande taak kunt opnemen. --status gaat een stap verder en geeft helemaal geen uitvoer, waardoor alleen de exit-status overblijft. Wijs hetzelfde patroon aan naar de werkelijke bestanden met sha256sum /usr/local/bin/* > ~/local-bin.sha256 en u beschikt over een baseline. Paden worden exact zoals u ze heeft getypt in de lijst opgeslagen, dus absolute paden zorgen ervoor dat de controle vanuit elke directory werkt.

Wees u bewust van de waarde van deze baseline. Het detecteert een gewijzigd bestand. Het detecteert geen aanvaller die al over root-rechten beschikt, omdat die aanvaller inventory.sha256 net zo eenvoudig kan herschrijven als de binary zelf. Bewaar de lijst buiten de machine als u wilt dat deze betrouwbaar is; dit is onderdeel van de bredere vraag over in hoeverre u een VPS daadwerkelijk vertrouwt en wie er nog meer toegang heeft tot de onderliggende schijf.

FAQ

Betekent een overeenkomende checksum dat de download veilig is?

Nee. Het betekent dat de bytes die u heeft overeenkomen met de digest waarmee u ze heeft vergeleken. Als de aanvaller de pagina beheert waarop de digest is gepubliceerd, publiceren zij de digest van hun eigen bestand en geeft uw controle OK weer. Een overeenkomst is een bewering van consistentie. Een bewering van veiligheid vereist een handtekening die is geverifieerd met een sleutel die u uit een andere bron heeft verkregen; pas dan erft de digest dat vertrouwen.

Waarom geeft sha256sum -c de melding FAILED open or read?

Omdat het bestand niet is gelezen. Een aparte regel direct daarboven vermeldt No such file or directory met de naam die het zocht. De namen in een SHA256SUMS-bestand zijn relatief ten opzichte van de map waarin u het commando uitvoert. Ga dus naar de map met de download en voer het commando opnieuw uit. Als de lijst ook bestanden bevat die u niet heeft gedownload, voeg dan --ignore-missing toe. Een eenvoudige FAILED zonder open or read is de tegenovergestelde situatie: het bestand is gelezen en de digest kwam niet overeen.

Is MD5 goed genoeg voor het verifiëren van een download?

Voor incidentele schade wel. Een afgebroken overdracht of een defecte schijfsector zal niet per toeval een overeenkomende MD5-digest produceren. Tegen een aanvaller niet. Twee verschillende bestanden met dezelfde MD5-digest zijn sinds 2004 te construeren, en SHA-1 is in 2020 bezweken onder een 'chosen-prefix collision'. Gebruik de SHA-256-regel wanneer een project beide publiceert, en beschouw een project dat alleen MD5 aanbiedt als een teken van een verouderd releaseproces.

Wat is het verschil tussen sha256sum -c en gpg --verify?

sha256sum -c bewijst dat een bestand overeenkomt met een digest. gpg --verify bewijst dat een digest-bestand is ondertekend door de houder van een specifieke privésleutel. Ze beantwoorden verschillende vragen, dus voer beide uit wanneer een project beide aanbiedt. De handtekening maakt de digest-lijst betrouwbaar, en de digest-lijst maakt vervolgens het gedownloade bestand betrouwbaar.

Hoe controleer ik één bestand tegen een digest die op een webpagina staat?

Vergelijk de tekens niet met het blote oog. Sla de digest en de bestandsnaam op één regel op, gescheiden door twee spaties, en voer vervolgens sha256sum -c uit op dat bestand en lees de OK of FAILED die het weergeeft. Het opbouwen van de regel met printf '%s %s\n' voorkomt de opmaakfouten waardoor sha256sum het bestand afwijst met no properly formatted checksum lines found.