Как проверить контрольную сумму файла в Linux

Проверка загруженного файла по контрольной сумме за две минуты

Чтобы проверить загруженный файл с помощью контрольной суммы, вычислите хеш полученного файла и сравните его с тем, который опубликовал автор. Утилита sha256sum выполняет обе части этой задачи: сама по себе она выводит дайджест, а с флагом -c считывает список дайджестов и сообщает, какие файлы совпадают. В этом руководстве мы проделаем весь цикл с созданным вами файлом, а затем намеренно повредим его, чтобы вы увидели процесс сбоя на практике, а не просто прочитали о нём.

На протяжении всего процесса помните одну важную мысль. Контрольная сумма показывает, что байты, которые у вас есть, соответствуют тем, из которых был получен дайджест, но она ничего не говорит о том, кто их создал. Для ответа на второй вопрос требуются цифровая подпись и ключ, которому вы доверяете. В последней части этого руководства показано, где именно проходит граница между этими двумя понятиями.

Создание файла для практики

Работайте в рабочем каталоге, чтобы ваши действия не затрагивали остальную часть системы. Все приведенные ниже команды входят в состав GNU coreutils — базового набора утилит, присутствующего на любом сервере Ubuntu или Debian, поэтому ничего дополнительно устанавливать не нужно.

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

Вы получите одну строку: 64 шестнадцатеричных символа, два пробела и имя файла. Эти 64 символа представляют собой дайджест файла. Запустите команду снова, и строка останется прежней, так как хеширование детерминировано: один и тот же входной сигнал всегда дает один и тот же результат. Измените один символ в файле и запустите команду снова — дайджест не изменится лишь незначительно. Он будет выглядеть совершенно иначе, так как изменение одного входного бита приводит к изменению примерно половины выходных битов. Именно это свойство позволяет использовать 64-символьную строку в качестве полноценной замены образа объемом 4 GB.

Сохранение файла SHA256SUMS и его проверка

Хэш-сумма на экране бесполезна уже на следующий день. Запишите её в файл в формате, который использует сама sha256sum, чтобы утилита могла прочитать его позже.

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

sha256sum -c считывает каждую строку из списка, вычисляет хэш файла, указанного в этой строке, и сравнивает его с контрольной суммой. При успешной проверке для каждого файла выводится одна строка:

payload.txt: OK

Также проверяйте код завершения, так как скрипты считывают именно его, а не текстовый вывод. echo $? выводит 0 после успешного выполнения. Имя SHA256SUMS — это скорее соглашение, чем строгое правило, но дистрибутивы и большинство страниц с релизами используют именно его. Придерживайтесь этого стандарта, чтобы другие пользователи понимали содержимое файла, не открывая его.

Измените один байт, чтобы проверка завершилась ошибкой

Теперь намеренно повредите файл. Следующая команда записывает один байт по смещению 5, не затрагивая остальное содержимое, поэтому размер и имя файла остаются прежними.

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

Флаг conv=notrunc здесь критически важен: без него dd обрезает файл в точке завершения записи, и вы будете тестировать гораздо более очевидный тип повреждения. Теперь проверка выведет следующее:

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

echo $? выводит 1. Код FAILED означает, что файл был прочитан, но его контрольная сумма не совпала с той, что указана в списке. Верните исходные байты на место и убедитесь, что проверка снова возвращает OK:

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

В этом и заключается вся суть метода. Разница всего в один байт в любом месте файла приводит к FAILED. Прерванная из-за разрыва соединения загрузка, зеркало, отдающее устаревшую сборку, прокси-сервер, изменивший файл при передаче, или диск, вернувший поврежденный блок — все эти ситуации приводят к одной и той же ошибке.

Если в списке указан файл, который вы не скачивали

Файл SHA256SUMS от дистрибутива содержит перечень всех образов, которые выпускает проект, а вы скачали только один из них. Воспроизведите эту ситуацию здесь.

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 — это ошибка, отличная от FAILED, и их смешение приводит к потере времени. FAILED означает, что байты не совпадают. FAILED open or read означает, что sha256sum вообще не получил файл, поэтому сравнение не проводилось. При реальной загрузке типичная причина кроется в рабочем каталоге, так как имена в списке указываются относительно того места, откуда вы запускаете команду. Перейдите в каталог, содержащий файл, и запустите команду снова. Чтобы проверить только то, что у вас есть, укажите это явно:

sha256sum --ignore-missing -c SHA256SUMS.all

Эта команда выведет payload.txt: OK и завершится с кодом 0. Если ни одного из перечисленных имен нет в наличии, --ignore-missing не завершится молчаливым успехом при нуле обработанных файлов. Она сообщит, что no file was verified, и завершится с ненулевым кодом. Это именно то поведение, которое вам нужно, так как проверка, которая ничего не проконтролировала — это сбой, который вы могли бы не заметить.

Вставка опубликованного дайджеста без визуальной проверки

Сравнение 64 шестнадцатеричных символов на глаз — это именно то место, где данная привычка подводит. Люди проверяют первые четыре символа и последние четыре, считая их совпавшими, а именно на это и рассчитывает целеустремленный злоумышленник. Позвольте инструменту выполнить сравнение за вас. Присвойте переменной EXPECTED дайджест, скопированный у издателя, используя EXPECTED=, за которой следует вставленное значение, а затем сформируйте одну строку, которую ожидает -c:

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

Между дайджестом и именем файла должны стоять два пробела, поэтому строка формата содержит их два. Именно в таком виде sha256sum записывает данные, и именно такой формат ожидает -c при чтении. Файл, содержащий только дайджест, не является корректной строкой контрольной суммы, поэтому проверка отклонит весь файл с ошибкой no properly formatted checksum lines found, вместо того чтобы пытаться угадать, какой файл вы имели в виду. Некоторые проекты публикуют хеши в стиле BSD, используя SHA256 (payload.txt) = перед дайджестом. GNU coreutils записывает данные в таком формате с помощью sha256sum --tag payload.txt и считывает их обратно через -c, поэтому для сохранения подходит любой из этих вариантов.

Если проверка ведет себя странно, изучите список с помощью cat -A SHA256SUMS: эта команда помечает конец каждой строки символом $ и отображает невидимые символы. Строка, заканчивающаяся на ^M$, содержит символ возврата каретки, добавленный Windows-редактором. GNU sha256sum игнорирует этот завершающий символ и по-прежнему выводит OK, поэтому список в формате CRLF не является причиной сбоя проверки, хотя инструменты вне coreutils менее терпимы к таким особенностям. Приведите сохраненную копию к нормальному виду с помощью tr -d '\r' < SHA256SUMS > SHA256SUMS.clean.

Что доказывает контрольная сумма, а что — нет?

Контрольная сумма доказывает только одно: байты на вашем диске совпадают с байтами, из которых был получен опубликованный дайджест. Это полностью защищает от случайных повреждений. Также это помогает против невнимательного злоумышленника, который подменил файл на зеркале для скачивания, но не смог изменить страницу, где был опубликован дайджест.

Она ничего не доказывает об авторстве. Дайджест — это факт о байтах, а не факт о людях. Если одна и та же страница предоставляет и файл, и дайджест, то любой, кто может изменить одно, может изменить и другое, и ваша строка OK будет означать лишь то, что зеркало согласно само с собой. Поэтому вот правило, которое делает проверку контрольных сумм полезной: берите дайджест из источника, отличного от того, где вы взяли файл. Например, с официального домена проекта по протоколу TLS (transport layer security), в то время как образ был получен через зеркало или торрент. Теперь злоумышленнику нужно контролировать два места вместо одного.

Алгоритм также имеет значение. У SHA-256 (secure hash algorithm, 256-битный вывод) по состоянию на август 2026 года нет известных коллизий, поэтому издатели используют именно его. MD5 (message digest 5) и SHA-1 больше не подходят: два разных файла с одинаковым дайджестом MD5 можно было создать еще в 2004 году, а коллизия SHA-1 с выбранным префиксом была опубликована в 2020 году. Файл MD5SUMS все еще позволяет обнаружить прерванную загрузку, так как случайное повреждение — это не специально созданная коллизия. Однако это не остановит того, кто пытается вас обмануть. Если проект публикует оба варианта, используйте строку SHA-256.

Где вступают в силу подписи

Цифровая подпись закрывает брешь, которую оставляет после себя хеш-сумма. Издатель подписывает файл с хеш-суммами своим закрытым ключом, а вы проверяете его с помощью открытого ключа: gpg --verify SHA256SUMS.asc SHA256SUMS. Если проверка проходит успешно, это означает, что список хеш-сумм был создан владельцем данного ключа. Затем sha256sum -c SHA256SUMS связывает файл на вашем диске с этим списком, и цепочка доверия выстраивается от ключа непосредственно до байтов данных.

Слабым звеном становится сам ключ. Если загрузить ключ с той же страницы, где был получен файл, злоумышленник может подменить обе части. GnuPG прямо предупреждает об этом: при первой проверке выводится Good signature вместе с WARNING: This key is not certified with a trusted signature!. Good signature означает лишь то, что математическая проверка прошла успешно. Это не гарантирует, что ключ принадлежит именно тому проекту, который вам нужен. Получите отпечаток ключа из независимого источника, например, из документации проекта на другом домене или из дистрибутивного пакета, который уже содержит этот ключ. Сравнивайте полный отпечаток, а не только последние восемь символов. Это требует такой же осторожности, как и обращение с закрытым ключом SSH, по той же причине: ключ — это основа доверия, и всё, что следует за ним, наследует это доверие.

Воспроизводимые сборки (reproducible builds) развивают эту идею дальше. Опубликованная хеш-сумма всё ещё привязывает вас к бинарному файлу, собранному на одной конкретной машине. Когда сборка проекта воспроизводима, любой желающий может скомпилировать тот же исходный код и получить идентичный побайтовый результат. Таким образом, независимые сборщики могут подтвердить опубликованную хеш-сумму, вместо того чтобы полагаться на честное слово одного сервера. Это становится всё более важным с каждым годом, так как всё больше кода поступает через автоматизированные конвейеры и создаётся с помощью машинных патчей. Решение о том, что именно вы принимаете в сборку, — это вопрос политики, и политики open source для кода, созданного с помощью ИИ работают с той же цепочкой поставок, но с другой стороны.

Ваш менеджер пакетов уже делает это за вас

В Debian и Ubuntu apt выполняет эту цепочку при каждой установке без дополнительных запросов. Индекс пакетов содержит SHA-256 дайджест для каждого файла .deb. Файл Release содержит дайджесты этих индексных файлов, а InRelease содержит подпись для Release, которая проверяется по ключам в /usr/share/keyrings и /etc/apt/trusted.gpg.d. Если цепочка нарушается, apt сообщает об этом: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY при отсутствии ключа стороннего репозитория или Hash Sum mismatch, когда полученный индекс не совпадает с подписанным Release, что обычно означает, что кэширующий прокси выдал устаревший файл или вы обратились к зеркалу в процессе синхронизации.

Это стандарт, с которым следует сравнивать ситуацию, когда на домашней странице проекта вам предлагают передать скрипт из curl напрямую в оболочку. Ничто не проверяет байты, и вы их никогда не видите. Сервер также может вернуть одно содержимое скрипту, а другое — браузеру, и у вас не останется копии для последующей проверки. Скачайте файл с помощью curl -fsSL <url> -o install.sh, вычислите его хэш, изучите содержимое через less и только после этого запускайте. Эта привычка отнимает около двадцати секунд, и именно с неё стоит начать работу на новом VPS в первые десять минут, прежде чем на сервере будет установлено что-либо ещё.

Сохраняйте список хеш-сумм для того, что устанавливаете вручную

Пакеты, установленные через apt, отслеживаются системой. Бинарный файл, который вы скопировали в /usr/local/bin, не отслеживается, и ни один системный механизм за ним не наблюдает. Список хеш-сумм превращает такой файл в объект, который можно проверить по запросу:

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

--quiet ничего не выводит, если все файлы соответствуют контрольным суммам, и выводит только строки с ошибками, если есть несоответствия. Таким образом, отсутствие вывода означает успешную проверку, а echo $? подтверждает это с помощью 0. Эту конструкцию следует использовать в запланированных задачах. --status работает еще строже и вообще ничего не выводит, оставляя только код завершения. Укажите тот же шаблон для реальных файлов с помощью sha256sum /usr/local/bin/* > ~/local-bin.sha256, и вы получите базовый уровень (baseline). Пути сохраняются в списке в том виде, в котором вы их ввели, поэтому использование абсолютных путей позволяет выполнять проверку из любой директории.

Четко осознавайте ценность этого базового уровня. Он обнаруживает изменение файла. Он не обнаружит злоумышленника, который уже получил права root, так как этот злоумышленник может перезаписать inventory.sha256 так же легко, как он перезаписал бинарный файл. Храните список вне машины, если хотите, чтобы он имел хоть какой-то смысл. Это часть более широкого вопроса о том, насколько вы на самом деле доверяете своему VPS и кто еще может получить доступ к диску на уровне ниже операционной системы.

FAQ

Означает ли совпадение контрольной суммы, что файл безопасен?

Нет. Это означает лишь то, что байты вашего файла соответствуют дайджесту, с которым вы их сравнили. Если злоумышленник контролирует страницу, на которой опубликован дайджест, он опубликует дайджест своего собственного файла, и ваша проверка выведет OK. Совпадение — это подтверждение целостности данных. Для подтверждения безопасности необходима цифровая подпись, проверенная ключом, полученным из независимого источника; только тогда дайджест наследует это доверие.

Почему sha256sum -c выводит FAILED open or read?

Потому что программа не нашла файл. Строкой выше обычно выводится No such file or directory с именем файла, который она искала. Имена внутри файла SHA256SUMS указываются относительно директории, в которой вы запускаете команду, поэтому перейдите в директорию с загруженным файлом и запустите команду снова. Если в списке есть файлы, которые вы не скачивали, добавьте флаг --ignore-missing. Обычный вывод FAILED без open or read означает обратную ситуацию: файл был прочитан, но его дайджест не совпал.

Достаточно ли MD5 для проверки загруженного файла?

Для защиты от случайных повреждений — да. Неполная передача данных или сбойный сектор диска не дадут случайно совпадающий дайджест MD5. Для защиты от злоумышленника — нет. Два разных файла с одинаковым дайджестом MD5 можно создать с 2004 года, а SHA-1 стал уязвим к коллизиям с выбранным префиксом в 2020 году. Используйте строку SHA-256, если проект публикует оба варианта, а наличие только MD5 указывает на устаревший процесс выпуска релизов.

В чем разница между sha256sum -c и gpg --verify?

sha256sum -c доказывает, что файл соответствует дайджесту. gpg --verify доказывает, что файл с дайджестами был подписан владельцем конкретного закрытого ключа. Они отвечают на разные вопросы, поэтому выполняйте обе проверки, если проект предлагает оба варианта. Подпись делает список дайджестов достоверным, а список дайджестов затем делает достоверным сам загруженный файл.

Как проверить один файл по дайджесту, опубликованному на веб-странице?

Не сравнивайте символы визуально. Сохраните дайджест и имя файла в одной строке, разделив их двумя пробелами, затем запустите sha256sum -c для этого файла и прочитайте OK или FAILED, которые выведет программа. Формирование строки с помощью printf '%s %s\n' позволяет избежать ошибок форматирования, из-за которых sha256sum отклоняет файл с сообщением no properly formatted checksum lines found.