A checksum (hash) is a short fingerprint of a file’s contents. If even one bit changes, the checksum changes. On servers you use checksums to make sure downloads aren’t corrupted or tampered with, that backups and transfers arrived intact, and to detect changed files.

Which algorithm?

Algorithm Command Use
SHA-256 sha256sum Default choice: integrity and security
SHA-512 sha512sum Also secure; longer output
MD5 md5sum Fast integrity checks only. Not secure against tampering
SHA-1 sha1sum Legacy; avoid for security
BLAKE2 / b3sum b2sum, b3sum Very fast, secure

Use SHA-256 unless a source publishes only another hash.

Generate a checksum

sha256sum ubuntu-24.04-live-server-amd64.iso
# <64 hex characters>  ubuntu-24.04-live-server-amd64.iso

sha256sum backup.tar.zst > backup.tar.zst.sha256

Verify a download

Most projects publish a SHA256SUMS file next to their downloads:

wget https://releases.example.org/1.2.3/app-1.2.3.tar.gz
wget https://releases.example.org/1.2.3/SHA256SUMS
sha256sum -c SHA256SUMS --ignore-missing
# app-1.2.3.tar.gz: OK

Or compare against a single published value:

echo "<published-hash>  app-1.2.3.tar.gz" | sha256sum -c -

(Two spaces between the hash and the file name.)

Authenticity: checksums + GPG signatures

A checksum proves the file matches the checksum file. But if an attacker replaced both on a compromised download server, they’d still match. Projects sign their checksum files with GPG to prove who published them:

wget https://releases.example.org/1.2.3/SHA256SUMS.asc
gpg --keyserver hkps://keys.openpgp.org --recv-keys <publisher-key-id>
gpg --verify SHA256SUMS.asc SHA256SUMS
# Good signature from "Example Release Team <[email protected]>"
sha256sum -c SHA256SUMS --ignore-missing

Get the publisher’s key fingerprint from a trusted source (the project’s website over HTTPS, or documentation), not just from the same download directory.

Verify backups and transfers

# before transfer
sha256sum *.tar.zst > manifest.sha256
# after transfer, on the other server
sha256sum -c manifest.sha256

rsync checks transfers internally, but end-to-end checksums also catch problems after the transfer (disk errors, partial copies). See rsync examples and split large files.

Checksums for a whole directory

cd /var/www/site
find . -type f -exec sha256sum {} + | sort -k2 > /root/site.sha256
# later: what changed?
sha256sum -c --quiet /root/site.sha256

Only files that fail are listed. That’s a quick way to detect modified files after a suspected compromise (store the manifest off the server, so an attacker can’t update it). For continuous monitoring, use file integrity tools such as AIDE. See detect a compromised server.

Package-managed files can be verified against the package database: debsums -c (Debian/Ubuntu) or rpm -Va (RHEL family).

Windows and macOS equivalents

  • Windows PowerShell: Get-FileHash file.iso -Algorithm SHA256.
  • macOS: shasum -a 256 file.iso.

Common mistakes

  • Comparing by eye: hashes differ in subtle places. Let sha256sum -c do the comparison.
  • Wrong line format: checksum files need two spaces (or a space and an asterisk for binary mode) between the hash and the name.
  • Checking the checksum file from the same compromised source: use GPG signatures, or get the hash from an independent, trusted page.
  • Line endings: checksum files edited on Windows can have CRLF line endings, which make sha256sum -c fail. Convert with dos2unix.

Quick reference

Task Command
SHA-256 of a file sha256sum file
Save checksums sha256sum files > list.sha256
Verify sha256sum -c list.sha256
Only listed files present --ignore-missing
Verify signature gpg --verify SHA256SUMS.asc SHA256SUMS
Package files debsums -c / rpm -Va

Related: 7-Zip on Linux and Linux server hardening checklist.

  • Linux
  • Security
  • Command Line