Как проверить контрольную сумму файла в 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 ГБ образа.

Сохранение файла 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 не является причиной сбоя проверки, хотя сторонние инструменты могут быть менее терпимы к таким особенностям. Приведите копию файла к нормальному виду с помощью tr -d '\r' < SHA256SUMS > SHA256SUMS.clean.

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

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

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

Алгоритм также имеет значение. У SHA-256 (secure hash algorithm, 256-bit output) по состоянию на август 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, по той же причине: ключ является основой доверия, и всё, что следует за ним, наследует это доверие.

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

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

В 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, чтобы создать базовую конфигурацию. Пути сохраняются в списке в том виде, в котором вы их ввели, поэтому использование абсолютных путей позволяет выполнять проверку из любого каталога.

Четко осознавайте ценность такой базовой конфигурации. Она обнаруживает изменение файла. Она не обнаружит злоумышленника, который уже получил права 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.