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, genereert u een hash van het ontvangen bestand en laat u een tool deze hash vergelijken met de hash die de uitgever heeft gepubliceerd. sha256sum voert beide delen 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 procedure met een bestand dat u zelf aanmaakt, waarna u het bestand opzettelijk beschadigt om de foutmelding in de praktijk te zien in plaats van er alleen over 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 vertelt u 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.

Een bestand aanmaken om mee te oefenen

Werk in een tijdelijke map zodat uw acties geen invloed hebben op de rest van het systeem. Elk onderstaand commando is onderdeel van GNU coreutils, de standaardset met commando's 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 te zien: 64 hexadecimale tekens, twee spaties en vervolgens de bestandsnaam. Die 64 tekens vormen de hash van het bestand. Voer het commando 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 het commando opnieuw uit; de hash verschuift niet slechts een klein beetje. De reeks ziet er volledig anders uit, omdat het wijzigen van één bit in de invoer ongeveer de helft van de uitvoerbits doet kantelen. Die eigenschap maakt een tekenreeks van 64 tekens een bruikbare vervanger voor een image van 4 GB.

Sla een SHA256SUMS-bestand op en controleer dit vervolgens

Een hash op het scherm is een dag later waardeloos. Schrijf deze naar een bestand in het formaat dat sha256sum zelf gebruikt, zodat de tool het later weer 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 beide hashes. Een succesvolle uitvoering geeft één regel per bestand weer:

payload.txt: OK

Controleer ook de exit-status, aangezien een script dit leest en nooit de tekst zelf verwerkt. echo $? geeft 0 weer na een foutloze uitvoering. De naam SHA256SUMS is eerder een conventie dan 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 een enkele 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. Zet 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 serveert, een proxy die het bestand tijdens het transport heeft herschreven, een schijf die een defect blok retourneerde: ze leiden allemaal tot diezelfde regel.

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 specifiek om dat bestand:

sha256sum --ignore-missing -c SHA256SUMS.all

Dit print payload.txt: OK 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 foutcode, wat het gewenste gedrag is. Een controle die niets heeft gecontroleerd, is immers een fout 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; daarom bevat de format-string er twee. Dit is de vorm die sha256sum schrijft en die -c parseert. Een bestand dat enkel een digest bevat, is geen checksum-regel; de controle wijst het hele bestand daarom 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 die 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$ heeft een carriage return opgepikt uit een Windows-editor. GNU sha256sum negeert dat laatste 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, 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. Dit is daarom de regel die het uitvoeren van checksums zinvol maakt: haal de digest ergens anders vandaan dan waar u het bestand heeft gehaald. Bijvoorbeeld het eigen domein van het project via TLS (transport layer security), terwijl de image van een mirror of een torrent kwam. Nu moet een aanvaller twee locaties beheersen in plaats van één. Het zegt ook niets over wat die geverifieerde bytes zullen doen zodra u ze uitvoert; een afzonderlijke vraag die het waard is om te stellen bij alles wat namens u wordt uitgevoerd, van een installatiescript tot een dsh-plugin die draait met de rechten van uw agent.

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 SHA-1-botsing met gekozen prefix werd in 2020 gepubliceerd. Een MD5SUMS-bestand detecteert nog steeds een afgebroken download, omdat willekeurige corruptie geen doelbewust geconstrueerde 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 die het bestand aanbiedt, geeft beide helften in handen van een aanvaller. 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 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 dat de key al bevat, 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 vertrouwen, en alles wat daarop volgt erft dit vertrouwen over.

Reproducible 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-identiek resultaat 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 toeleveringsketen 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 doorbroken, 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 hebt getroffen.

Dat is de standaard waaraan u moet toetsen wanneer de website van een project u adviseert 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 iets anders teruggeven aan een script dan aan een browser, en u hebt 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 het 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 machine 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 maakt dit controleerbaar op aanvraag:

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 nog een stap verder en geeft helemaal geen uitvoer, waardoor alleen de exit-status overblijft. Wijs hetzelfde patroon aan met sha256sum /usr/local/bin/* > ~/local-bin.sha256 naar de daadwerkelijke bestanden om een baseline te creëren. Paden worden in de lijst opgeslagen zoals u ze heeft getypt; gebruik daarom absolute paden zodat de controle vanuit elke directory werkt.

Wees u bewust van de waarde van deze baseline. Het detecteert een gewijzigd bestand. Het detecteert echter geen aanvaller die al root-rechten heeft, 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 blijft. 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 aan. Een overeenkomst is een bewijs van consistentie. Een veiligheidsclaim 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 wel gelezen, maar 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, 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.