Como verificar integridad de archivos con sha256sum

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

Para verificar una descarga con una suma de comprobación, genere el hash del archivo recibido y deje que una herramienta compare ese hash con el que publicó el autor. sha256sum realiza ambas partes del proceso: por sí solo imprime un resumen, y con -c lee una lista de resúmenes e informa qué archivos coinciden. Esta guía ejecuta el ciclo completo sobre un archivo que usted crea, y luego lo altera a propósito para que observe el fallo en lugar de solo leer sobre él.

Tenga presente una frase durante todo el proceso. Una suma de comprobación le indica si los bytes que usted posee son los mismos que generaron el resumen, pero no le dice nada sobre quién los produjo. Esa segunda cuestión requiere una firma y una clave en la que usted confíe. La última parte de esta guía muestra exactamente dónde se encuentra la línea divisoria entre ambos conceptos.

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 provienen de GNU coreutils, el conjunto de comandos base presente en cualquier servidor Ubuntu o Debian, por lo que no hay nada que instalar.

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 luego el nombre del archivo. Esos 64 caracteres son el resumen (digest) del archivo. Ejecute el comando de nuevo y la línea será idéntica, ya que el hashing es determinista: la misma entrada siempre produce la misma salida. Cambie un solo carácter del archivo y ejecútelo otra vez; el resumen no cambiará solo un poco. Se verá completamente diferente, porque cambiar un bit de entrada altera aproximadamente la mitad de los bits de salida. Esa propiedad es lo que hace que una cadena de 64 caracteres sea un sustituto válido para una imagen de 4 GB.

Guardar un archivo SHA256SUMS y verificarlo

Un resumen (digest) en pantalla no sirve de nada al día siguiente. Escríbalo en un archivo, usando el formato que el propio sha256sum genera, para que la herramienta pueda leerlo más tarde.

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 dicha línea y compara ambos resúmenes. Una ejecución correcta imprime una línea por archivo:

payload.txt: OK

Compruebe también el estado de salida, ya que un script lee ese valor y no el texto. echo $? imprime 0 tras una ejecución limpia. El nombre SHA256SUMS es una convención más que una regla, pero las distribuciones y la mayoría de las páginas de versiones lo utilizan; úselo también para que el siguiente usuario sepa qué contiene el archivo sin necesidad de abrirlo.

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

Ahora corrompa el archivo a propósito. Esto escribe un solo byte en el desplazamiento 5 y deja el resto intacto, por lo que el archivo mantiene 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 el flag importante: sin él, 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 $? imprime 1. FAILED significa que el archivo se leyó y su resumen (digest) no coincidió con el de la lista. Restaure los bytes originales y confirme que la comprobación vuelve a OK:

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

Ese es todo el hábito. Un byte de diferencia, en cualquier parte del archivo, produce FAILED. Una descarga interrumpida por una conexión caída, un espejo que sirve una compilación antigua, un proxy que reescribió el archivo durante el tránsito, un disco que devolvió un bloque defectuoso: todos terminan en esa misma línea.

Cuando la lista menciona un archivo que no ha descargado

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

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 error distinto a FAILED, y confundirlos le hará perder tiempo. FAILED significa que los bytes son incorrectos. FAILED open or read significa que sha256sum nunca obtuvo el archivo, por lo que no se realizó ninguna comparación. En una descarga real, la causa habitual es el directorio de trabajo, ya que los nombres en la lista son relativos a la ubicación donde ejecuta el comando. Acceda al directorio que contiene el archivo y ejecútelo de nuevo. Para comprobar solo lo que realmente tiene, solicítelo específicamente:

sha256sum --ignore-missing -c SHA256SUMS.all

Esto imprime payload.txt: OK y termina con código 0. Si ninguno de los nombres listados está presente, --ignore-missing no tiene éxito silencioso con cero archivos. Informa que no file was verified y termina con un código distinto de cero, que es el comportamiento esperado, ya que una validación que no comprobó nada es el fallo que usted nunca notaría.

Pegar un resumen publicado sin leerlo visualmente

Comparar 64 caracteres hexadecimales a simple vista es donde este hábito falla. Las personas comprueban los primeros cuatro caracteres y los últimos cuatro y lo dan por válido, y esa es exactamente la comparación que un atacante decidido espera. Deje que la herramienta realice la comparación. Asigne EXPECTED al resumen que copió del editor, usando EXPECTED= seguido del valor pegado, y luego construya la línea única que -c espera:

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

Hay dos espacios entre el resumen y el nombre del archivo, por lo que la cadena de formato incluye dos. Esa es la estructura que sha256sum escribe y la que -c analiza. Un archivo que contiene solo un resumen no es una línea de suma de comprobación, por lo que la verificación rechaza todo el archivo con no properly formatted checksum lines found en lugar de intentar adivinar a qué archivo se refiere. Algunos proyectos publican el estilo etiquetado BSD, SHA256 (payload.txt) = seguido del resumen. GNU coreutils escribe ese formato con sha256sum --tag payload.txt y lo lee con -c, por lo que cualquiera de los dos formatos es válido para guardar.

Cuando una verificación se comporte de forma extraña, examine la lista con cat -A SHA256SUMS, que marca el final de cada línea con $ y muestra caracteres que de otro modo no podría ver. Una línea que termina en ^M$ ha capturado un retorno de carro de un editor de Windows. GNU sha256sum ignora ese carácter final y aun así imprime OK, por lo que una lista con CRLF no es lo que rompe la verificación, aunque las herramientas ajenas a coreutils son menos tolerantes al respecto. Normalice la copia que conserve 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 en su disco son los mismos que produjeron el resumen publicado. Esto cubre completamente el daño accidental. También cubre a un atacante descuidado que sustituyó el archivo en un espejo de descarga pero no pudo acceder a la página que publicó el resumen.

No demuestra nada sobre la autoría. Un resumen es un hecho sobre los bytes, no un hecho sobre las personas. Si una página sirve tanto el archivo como el resumen, entonces quien pueda cambiar uno puede cambiar el otro, y su línea OK solo significa que el espejo coincide consigo mismo. Por lo tanto, esta es la regla que hace que valga la pena ejecutar sumas de comprobación: obtenga el resumen de un lugar distinto al que obtuvo el archivo. Por ejemplo, el dominio propio del proyecto a través de TLS (transport layer security), mientras que la imagen provino de un espejo o un torrent. Ahora, un atacante debe controlar dos lugares en lugar de uno.

El algoritmo también importa. SHA-256 (secure hash algorithm, 256-bit output) no tiene colisiones conocidas a fecha de agosto de 2026, razón por la cual los editores lo utilizan. MD5 (message digest 5) y SHA-1 no son fiables: se han podido construir dos archivos diferentes con el mismo resumen MD5 desde 2004, y en 2020 se publicó una colisión de prefijo elegido para SHA-1. Un archivo MD5SUMS todavía detecta una descarga truncada, porque la corrupción aleatoria no es una colisión creada deliberadamente. No puede detener a alguien que intenta engañarle. Cuando un proyecto publica ambos, utilice la línea SHA-256.

Donde las firmas toman el control

Una firma cierra la brecha que deja abierta un resumen (digest). El editor firma el archivo de resumen con una clave privada y usted lo verifica con su clave pública: gpg --verify SHA256SUMS.asc SHA256SUMS. Si la verificación es correcta, la lista de resúmenes proviene de quien posee esa clave. Entonces, sha256sum -c SHA256SUMS vincula el archivo en su disco con la lista, y la cadena se extiende desde la clave hasta los bytes.

El punto débil se traslada a la clave. Obtener la clave desde la misma página que sirvió el archivo entrega ambas partes al atacante. GnuPG es transparente al respecto, y una primera verificación muestra Good signature junto con WARNING: This key is not certified with a trusted signature!. Good signature significa que la matemática es correcta. No significa que la clave pertenezca al proyecto que usted tiene en mente. Obtenga la huella digital (fingerprint) de una segunda fuente, como la documentación del proyecto en un dominio diferente o un paquete de distribución que ya incluya la clave, y compare la huella digital completa en lugar de los últimos ocho caracteres. Esto requiere el mismo cuidado que merece una clave privada SSH, por la misma razón: la clave es la decisión de confianza y todo lo que sigue en la cadena la hereda.

Las compilaciones reproducibles llevan la idea un paso más allá. Un resumen publicado todavía le vincula a un binario que una máquina compiló. 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, por lo que compiladores independientes pueden confirmar el resumen publicado en lugar de pedirle que confíe en la palabra de un solo servidor. Esto es cada vez más importante, a medida que llega más código a través de tuberías automatizadas y parches escritos 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 trabajan sobre la misma cadena de suministro desde el otro extremo.

Su gestor de paquetes ya hace esto por usted

En Debian y Ubuntu, apt ejecuta esta cadena en cada instalación sin que se le solicite. 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, verificada contra las claves en /usr/share/keyrings y /etc/apt/trusted.gpg.d. Cuando la cadena se rompe, apt lo notifica: 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 que obtuvo no coincide con el archivo Release firmado, lo que generalmente significa que un proxy de caché entregó un archivo obsoleto o que usted accedió a un espejo durante una sincronización.

Ese es el estándar con el que debe comparar cuando la página de inicio de un proyecto le indica que canalice un script desde curl directamente a un shell. Nada verifica los bytes y usted nunca los ve. El servidor también puede devolver una cosa a un script y otra distinta a un navegador, y usted no tendrá una copia para inspeccionar después. Descargue a un archivo con curl -fsSL <url> -o install.sh, calcule su hash, léalo con less y ejecútelo solo entonces. Este hábito toma unos veinte segundos, y es el mismo que vale la pena comenzar en un VPS nuevo en sus primeros diez minutos, antes de instalar cualquier otra cosa en el equipo.

Mantenga una lista de resúmenes (digests) para lo que instale manualmente

Los paquetes instalados mediante apt se rastrean automáticamente. Un binario que usted copió en /usr/local/bin no lo está, y nada en el sistema lo supervisa. Una lista de resúmenes convierte esto en algo que puede verificar bajo demanda:

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

--quiet no imprime nada cuando todos los archivos coinciden, y solo muestra las líneas que fallaron cuando alguno no lo hace; por lo tanto, el silencio es la señal de éxito y echo $? lo confirma con 0. Ese es el formato para incluir en una tarea programada. --status va más allá y no imprime absolutamente nada, dejando solo el estado de salida. Apunte el mismo patrón a archivos reales con sha256sum /usr/local/bin/* > ~/local-bin.sha256 y obtendrá una línea base. Las rutas se almacenan en la lista exactamente como las escribió, por lo que las rutas absolutas permiten que la verificación funcione desde cualquier directorio.

Sea claro sobre el valor de esa línea base. Detecta un archivo modificado. No detecta a un atacante que ya posee privilegios de root, porque ese atacante puede sobrescribir inventory.sha256 con la misma facilidad con la que sobrescribió el binario. Mantenga la lista fuera de la máquina si desea que tenga alguna validez, lo cual es parte de la cuestión más amplia sobre cuánta confianza deposita realmente en un VPS y quién más puede acceder al disco subyacente.

FAQ

¿Significa una suma de comprobación coincidente que la descarga es segura?

No. Significa que los bytes que usted tiene coinciden con el resumen (digest) con el que los comparó. Si el atacante controla la página que publicó el resumen, publicará el resumen de su propio archivo y su comprobación mostrará OK. Una coincidencia es una declaración de consistencia. Una declaración de seguridad requiere una firma verificada contra una clave obtenida de una fuente distinta; solo entonces el resumen hereda esa confianza.

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

Porque nunca leyó el archivo. Una línea independiente justo encima indica No such file or directory con el nombre que buscó. Los nombres dentro de un archivo SHA256SUMS son relativos al directorio donde ejecuta el comando, así que cámbiese al directorio que contiene la descarga y ejecútelo de nuevo. Si la lista también nombra archivos que usted no descargó, añada --ignore-missing. Un FAILED simple sin open or read es la situación opuesta: el archivo se leyó y su resumen no coincidió.

¿Es MD5 suficiente para verificar una descarga?

Para daños accidentales, sí. Una transferencia truncada o un bloque de disco defectuoso no producirán un resumen MD5 coincidente por azar. Contra un atacante, no. Es posible construir dos archivos diferentes con el mismo resumen MD5 desde 2004, y SHA-1 sucumbió a una colisión de prefijo elegido en 2020. Utilice la línea SHA-256 cuando un proyecto publique ambas, y considere un proyecto que solo ofrece MD5 como una señal de un proceso de lanzamiento antiguo.

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

sha256sum -c demuestra que un archivo coincide con un resumen. gpg --verify demuestra que un archivo de resumen fue firmado por el poseedor de una clave privada específica. Responden a preguntas distintas, así que ejecute ambos cuando un proyecto ofrezca los dos. La firma hace que la lista de resúmenes sea confiable, y la lista de resúmenes hace que el archivo descargado sea confiable.

¿Cómo verifico un archivo contra un resumen publicado en una página web?

No compare los caracteres a simple vista. Guarde el resumen y el nombre del archivo en una sola línea, separados por dos espacios, luego ejecute sha256sum -c contra ese archivo y lea el OK o FAILED que muestra. 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.