Cómo verificar descargas con sha256sum en Linux

Verificar una descarga con una suma de comprobación en dos minutos

Para verificar una descarga con una suma de comprobación, calcule el hash del archivo recibido y deje que una herramienta compare ese hash con el que publicó el proveedor. sha256sum realiza las dos partes del proceso: por sí solo muestra un resumen criptográfico y, con -c, lee una lista de resúmenes e indica qué archivos coinciden. En esta guía se completa todo el proceso con un archivo que usted crea y después se modifica ese archivo de forma intencionada para observar el fallo en lugar de limitarse a leer sobre él.

Tenga presente una frase durante todo el proceso. Una suma de comprobación indica si los bytes que tiene son los bytes que produjeron el resumen, pero no indica quién los produjo. Para responder a esa segunda pregunta se necesita una firma y una clave en la que confíe. La última parte de esta guía muestra exactamente dónde está la diferencia entre ambas cosas.

Crear un archivo para practicar

Trabaje en un directorio temporal para que nada de lo que haga aquí afecte al resto del sistema. Todos los comandos siguientes forman parte de GNU coreutils, el conjunto básico de comandos presente en cualquier servidor Ubuntu o Debian, por lo que no es necesario instalar nada.

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

Obtendrá una línea: 64 caracteres hexadecimales, dos espacios y después el nombre del archivo. Esos 64 caracteres son el resumen criptográfico del archivo. Ejecute el comando de nuevo y la línea será idéntica, porque el hash es determinista: la misma entrada siempre produce la misma salida. Cambie un carácter del archivo y vuelva a ejecutarlo; el resumen no cambiará ligeramente. Será completamente distinto, porque cambiar un bit de la entrada cambia aproximadamente la mitad de los bits de la salida. Esta propiedad permite usar una cadena de 64 caracteres como representación de una imagen de 4 GB.

Guarde un archivo SHA256SUMS y compruébelo

Un resumen mostrado en pantalla no sirve un día después. Escríbalo en un archivo con el formato que genera sha256sum, para que la herramienta pueda leerlo más adelante.

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

sha256sum -c lee cada línea de la lista, calcula el hash del archivo indicado en esa línea y compara los dos resúmenes. Una ejecución correcta muestra una línea por archivo:

payload.txt: OK

Compruebe también el estado de salida, porque un script lo lee y nunca analiza el texto. echo $? muestra 0 después de una ejecución correcta. El nombre SHA256SUMS es una convención, no una regla, pero las distribuciones y la mayoría de las páginas de versiones lo utilizan. Úselo también para que la siguiente persona sepa qué contiene el archivo sin abrirlo.

Cambie un byte y observe cómo falla la comprobación

Ahora dañe el archivo de forma intencionada. Esto escribe un solo byte en el desplazamiento 5 y deja todo lo demás intacto, por lo que el archivo conserva su longitud y su nombre.

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

conv=notrunc es la opción importante: sin ella, dd trunca el archivo en el punto donde deja de escribir, y estaría probando un tipo de daño mucho más evidente. La comprobación ahora muestra:

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

echo $? muestra 1. FAILED significa que se leyó el archivo y que su resumen no coincide con el de la lista. Restaure los bytes originales y confirme que la comprobación vuelve a mostrar OK:

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

Ese es todo el procedimiento. Una diferencia de un solo byte, en cualquier posición del archivo, produce FAILED. Una descarga interrumpida por una conexión cortada, un mirror que sirve la compilación del día anterior, un proxy que modificó el archivo durante el tránsito o un disco que devolvió un bloque defectuoso: todos producen la misma línea.

Cuando la lista nombra un archivo que no descargó

Un archivo SHA256SUMS real de una distribución incluye todas las imágenes que el proyecto publica, y usted descargó una de ellas. Reproduzca aquí esa situación.

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 es un fallo distinto de FAILED, y confundirlos hace perder tiempo. FAILED significa que los bytes son incorrectos. FAILED open or read significa que sha256sum nunca encontró el archivo, por lo que no se comparó nada. En una descarga real, la causa habitual es el directorio de trabajo, porque los nombres de la lista son relativos al directorio desde el que ejecuta el comando. Cambie al directorio que contiene el archivo y ejecútelo de nuevo. Para comprobar sólo lo que realmente tiene, solicite esa comprobación:

sha256sum --ignore-missing -c SHA256SUMS.all

Esto muestra payload.txt: OK y termina con el código 0. Si no existe ninguno de los nombres incluidos en la lista, --ignore-missing no termina correctamente sin procesar ningún archivo. Informa de que no file was verified y termina con un código distinto de cero. Este es el comportamiento que necesita, porque una comprobación correcta que no verificó nada sería el fallo que nunca detectaría.

Pegar un resumen publicado sin leerlo a simple vista

Comparar a simple vista 64 caracteres hexadecimales es el punto en el que este hábito falla. Se comprueban los primeros cuatro caracteres y los últimos cuatro, y se da por válida la coincidencia. Esa es exactamente la comparación que espera un atacante decidido. Deje que la herramienta haga la comparación. Asigne a EXPECTED el resumen que copió del editor, mediante EXPECTED= seguido del valor pegado, y genere la única línea que espera -c:

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

Entre el resumen y el nombre de archivo hay dos espacios. Por eso la cadena de formato contiene dos. Esa es la estructura que escribe sha256sum y que analiza -c. Un archivo que contiene sólo un resumen no es una línea de suma de comprobación. Por tanto, la comprobación rechaza el archivo completo con no properly formatted checksum lines found en lugar de intentar adivinar qué archivo se quería comprobar. Algunos proyectos publican en su lugar el formato etiquetado de BSD: SHA256 (payload.txt) = seguido del resumen. GNU coreutils escribe ese formato con sha256sum --tag payload.txt y lo vuelve a leer con -c, así que se puede guardar cualquiera de las dos estructuras.

Cuando una comprobación se comporta de forma extraña, examine la propia lista con cat -A SHA256SUMS. Este comando marca el final de cada línea con $ y muestra caracteres que, de otro modo, no se pueden ver. Una línea que termina en ^M$ contiene un retorno de carro añadido por un editor de Windows. GNU sha256sum ignora ese carácter final y sigue mostrando OK. Por tanto, una lista CRLF no es lo que está rompiendo la comprobación, aunque las herramientas ajenas a coreutils son menos tolerantes con este formato. Normalice la copia que conserva con tr -d '\r' < SHA256SUMS > SHA256SUMS.clean.

¿Qué demuestra una suma de comprobación y qué no?

Una suma de comprobación demuestra una cosa: los bytes de su disco son los bytes que produjeron el resumen publicado. Esto cubre por completo los daños accidentales. También cubre a un atacante descuidado que sustituyó el archivo en un mirror de descarga, pero no pudo modificar la página donde se publicó el resumen.

No demuestra nada sobre la autoría. Un resumen es un hecho sobre bytes, no sobre personas. Si una misma página sirve el archivo y el resumen, quien pueda modificar uno podrá modificar el otro, y su línea `OK` sólo indica que el mirror coincide consigo mismo. Por eso, esta es la regla que hace que valga la pena ejecutar comprobaciones de suma: obtenga el resumen de un lugar distinto de aquel del que obtuvo el archivo. Por ejemplo, el dominio propio del proyecto mediante TLS (seguridad de la capa de transporte), mientras la imagen procede de un mirror o de un torrent. Así, un atacante tiene que controlar dos lugares en vez de uno. Tampoco indica qué harán esos bytes verificados cuando los ejecute. Esa es una cuestión independiente que conviene plantearse con cualquier elemento que se ejecute en su nombre, desde un script de instalación hasta un complemento dsh que se ejecuta con los permisos de su agente.

El algoritmo también importa. SHA-256 (algoritmo de resumen seguro, salida de 256 bits) no tiene ninguna colisión conocida a fecha de agosto de 2026, por eso los editores lo utilizan. MD5 (resumen de mensaje 5) y SHA-1 no son adecuados: desde 2004 es posible construir dos archivos distintos con el mismo resumen MD5, y en 2020 se publicó una colisión de SHA-1 con prefijo elegido. Un archivo `MD5SUMS` todavía detecta una descarga truncada, porque la corrupción aleatoria no es una colisión creada deliberadamente. No puede impedir que alguien intente engañarle. Si un proyecto publica ambos, utilice la línea de SHA-256.

Cuando las firmas pasan a ser necesarias

Una firma cierra la brecha que deja abierta un resumen criptográfico. El editor firma el archivo de resúmenes con una clave privada y usted lo comprueba con su clave pública: gpg --verify SHA256SUMS.asc SHA256SUMS. Si la comprobación es correcta, la lista de resúmenes procede de quien posee esa clave. Después, sha256sum -c SHA256SUMS vincula el archivo del disco con la lista, y la cadena se extiende desde la clave hasta los bytes.

El punto débil pasa a ser la clave. Descargarla de la misma página que proporcionó el archivo entrega ambas partes al atacante. GnuPG lo indica claramente: la primera comprobación muestra Good signature junto con WARNING: This key is not certified with a trusted signature!. Good signature significa que las operaciones matemáticas son correctas. No significa que la clave pertenezca al proyecto que usted cree. Obtenga la huella digital de una segunda fuente, como la documentación del proyecto en otro dominio o un paquete de la distribución que ya incluya la clave, y compare la huella digital completa en lugar de los últimos ocho caracteres. Este es el mismo cuidado que merece una clave privada SSH, por la misma razón: la clave determina la confianza y todo lo que depende de ella la hereda.

Las compilaciones reproducibles llevan esta idea un paso más allá. Un resumen publicado todavía le vincula a un binario que compiló una máquina. Cuando la compilación de un proyecto es reproducible, cualquiera puede compilar el mismo código fuente y obtener una salida idéntica byte a byte. Así, varios compiladores independientes pueden confirmar el resumen publicado, en lugar de pedirle que confíe en la palabra de un único servidor. Esto importa cada vez más, porque una mayor cantidad de código llega a través de pipelines automatizados y parches generados por máquinas. Decidir qué acepta en una compilación es una cuestión de política, y las políticas de código abierto para código asistido por IA actúan sobre la misma cadena de suministro desde el extremo opuesto.

El gestor de paquetes ya lo hace por usted

En Debian y Ubuntu, apt ejecuta esta cadena en cada instalación sin que tenga que solicitarlo. El índice de paquetes contiene un resumen SHA-256 para cada archivo .deb. El archivo Release contiene los resúmenes de esos archivos de índice, y InRelease contiene una firma sobre Release, que se comprueba con las claves de /usr/share/keyrings y /etc/apt/trusted.gpg.d. Cuando la cadena se rompe, apt lo indica: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY cuando falta la clave de un repositorio de terceros, o Hash Sum mismatch cuando el índice descargado no coincide con el Release firmado. Esto suele indicar que un proxy de caché entregó un archivo obsoleto o que se accedió a un mirror durante su sincronización.

Ese es el estándar que debe usar como referencia cuando la página del proyecto le indica que canalice un script desde curl directamente a un shell. No se verifica ningún byte y usted nunca ve el contenido. El servidor también puede devolver una cosa a un script y otra distinta a un navegador, y después no tendrá una copia para inspeccionarla. Descargue el archivo con curl -fsSL <url> -o install.sh, calcule su hash, léalo con less y ejecútelo sólo después. Este hábito cuesta unos veinte segundos y es el mismo que conviene adoptar en un VPS nuevo durante sus primeros diez minutos, antes de instalar cualquier otra cosa en el servidor.

Mantenga una lista de hashes de lo que instale manualmente

Los paquetes instalados mediante apt quedan registrados. Un binario que copie en /usr/local/bin no queda registrado, y ningún componente del sistema lo supervisa. Una lista de hashes permite comprobarlo cuando sea necesario:

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

--quiet no muestra nada cuando todos los archivos coinciden. Si alguno no coincide, sólo muestra las líneas que fallaron. Por tanto, el silencio indica que la comprobación se superó y echo $? lo confirma con 0. Este es el formato que debe usar en una tarea programada. --status va más allá y no muestra ninguna salida; sólo queda el código de salida. Aplique el mismo patrón a archivos reales con sha256sum /usr/local/bin/* > ~/local-bin.sha256 y tendrá una línea base. Las rutas se almacenan en la lista exactamente como se escribieron, por lo que las rutas absolutas permiten ejecutar la comprobación desde cualquier directorio.

Tenga claro qué valor tiene esa línea base. Detecta un archivo modificado. No detecta a un atacante que ya tenga acceso como root, porque puede reescribir inventory.sha256 con la misma facilidad con la que reescribió el binario. Mantenga la lista fuera de la máquina si quiere que sea útil. Esto forma parte de la cuestión más amplia de cuánto confía realmente en un VPS y de quién más puede acceder al disco subyacente.

FAQ

¿Un checksum coincidente significa que la descarga es segura?

No. Significa que los bytes que tiene coinciden con el resumen criptográfico contra el que los comparó. Si el atacante controla la página que publicó el resumen, publicará el resumen de su propio archivo y la comprobación mostrará OK. Una coincidencia sólo confirma la coherencia. Para confirmar la seguridad se necesita una firma verificada con una clave obtenida de otra fuente. Sólo entonces el resumen criptográfico hereda esa confianza.

¿Por qué sha256sum -c muestra FAILED open or read?

Porque nunca leyó el archivo. Justo encima aparece otra línea que dice No such file or directory con el nombre que buscó. Los nombres incluidos en un archivo SHA256SUMS son relativos al directorio desde el que ejecuta el comando. Cambie al directorio que contiene la descarga y vuelva a ejecutarlo. Si la lista también incluye archivos que no descargó, añada --ignore-missing. Un FAILED sin open or read indica la situación opuesta: el archivo se leyó, pero su resumen criptográfico no coincidió.

¿MD5 es suficiente para verificar una descarga?

Sí, para detectar daños accidentales. Una transferencia truncada o un bloque defectuoso del disco no producirá por casualidad un resumen MD5 coincidente. Contra un atacante, no. Desde 2004 es posible construir dos archivos diferentes con el mismo resumen MD5, y SHA-1 sufrió una colisión de prefijo elegido en 2020. Use la línea SHA-256 cuando un proyecto publique ambas. Interprete un proyecto que sólo use MD5 como señal de un proceso de publicación antiguo.

¿Cuál es la diferencia entre sha256sum -c y gpg --verify?

sha256sum -c demuestra que un archivo coincide con un resumen criptográfico. gpg --verify demuestra que el archivo de resúmenes fue firmado por el titular de una clave privada concreta. Responden a preguntas diferentes. Ejecute ambos cuando el proyecto ofrezca ambos. La firma hace fiable la lista de resúmenes. La lista de resúmenes hace fiable el archivo descargado.

¿Cómo compruebo un archivo con un resumen publicado en una página web?

No compare los caracteres visualmente. Guarde el resumen y el nombre del archivo en una sola línea, separados por dos espacios. Después ejecute sha256sum -c contra ese archivo y lea OK o FAILED, según lo que muestre. Construir la línea con printf '%s %s\n' evita los errores de formato que hacen que sha256sum rechace el archivo con no properly formatted checksum lines found.