Respuestas:
Puedes usar
openssl dgst -sha256 <file>
Probado en LibreSSL 2.6.4 en macOS 10.14 (Mojave).
Antes de Mojave puedes usar openssl sha -sha256 <file>
o openssl sha256 <file>
.
Para comprobar las opciones de línea de comandos para el comando openssl sha: openssl sha -help
.
OS X se envía con un comando shasum .
> which shasum
/usr/bin/shasum
Puedes usar:
> shasum -a 256 <file>
Más detalles:
> shasum --help
Usage: shasum [OPTION]... [FILE]...
Print or check SHA checksums.
With no FILE, or when FILE is -, read standard input.
-a, --algorithm 1 (default), 224, 256, 384, 512, 512224, 512256
-b, --binary read in binary mode
-c, --check read SHA sums from the FILEs and check them
-t, --text read in text mode (default)
-p, --portable read in portable mode
produces same digest on Windows/Unix/Mac
-0, --01 read in BITS mode
ASCII '0' interpreted as 0-bit,
ASCII '1' interpreted as 1-bit,
all other characters ignored
The following two options are useful only when verifying checksums:
-s, --status don't output anything, status code shows success
-w, --warn warn about improperly formatted checksum lines
-h, --help display this help and exit
-v, --version output version information and exit
When verifying SHA-512/224 or SHA-512/256 checksums, indicate the
algorithm explicitly using the -a option, e.g.
shasum -a 512224 -c checksumfile
The sums are computed as described in FIPS-180-4. When checking, the
input should be a former output of this program. The default mode is to
print a line with checksum, a character indicating type (`*' for binary,
` ' for text, `?' for portable, `^' for BITS), and name for each FILE.
Report shasum bugs to mshelor@cpan.org
which shashum
no produce nada
/usr/bin
con cosas opcionales. Tendré que verificar que este sea el caso más tarde hoy. Actualizará la respuesta si realmente vino de la instalación de XCL.
shasum
devuelve un hash diferente que openssl sha -sha256 <file>
(siendo este último el hash correcto). ¿Alguna idea de por qué?
shasum
es un script perl que se usa Digest::SHA
para calcular el valor hash. Para el mismo archivo obtengo exactamente el mismo SHA usando shasum
o openssl
para un SHA-256
cálculo hash. Ver: gist.github.com/ianchesal/82a064b8971eb5e717ce84f3ded6dbfd
Para aclarar la útil respuesta de @ John, que le permite comparar un hash dado con su archivo en un solo comando:
Ingrese shasum -a 256 -c <<<
,
seguido de un espacio opcional,
seguido de una sola marca ( '
),
seguido del hash para comparar,
seguido de un espacio,
seguido de un carácter de modo, en función de cómo se generó el hash inicial:
nada , si el hash se creó con -t
o sin opción (modo de texto, que es el predeterminado)
asterisco ( *
), si el hash se creó con -b
(modo binario)
signo de interrogación ( ?
), si el hash se creó con -p
(modo portátil)
caret ( ^
), si el hash se creó con -0
(modo bits)
seguido de la ruta al archivo,
seguido de un único tic de cierre ( '
).
Al igual que el siguiente desglose, con delimitación de elementos parecidos alrededor de las partes hash y ruta de archivo, y corchetes alrededor de la parte opcional "carácter de modo". ( No incluya los paréntesis ni los corchetes en la vida real, ¡solo están aquí para hacer que las piezas sean fáciles de ver! )
shasum -a 256 -c <<< '(hashToCompare) [mode character](filepath)'
Desglosado :
El comando shasum real esshasum -a 256 -c
-a 256
le dice shasum
que use sha256 .
-c
le dice shasum
a "verificar" la entrada proporcionada.
El <<<
es un juego de caracteres especiales de Unix / Linux, llamado operador de "redirección". Es para alimentar algo en un comando anterior. Al usarlo, estamos diciendo que vamos a proporcionar una cadena de información para que el shasum
comando la use como entrada.
La cadena de información de entrada debe tener marcas individuales de apertura y cierre, como 'some string here'
, o en este caso, el hash, el carácter de modo y la ruta de archivo a verificar.
La parte hash dentro de la cadena no necesita nada especial, pero debe ir seguida de un espacio.
La parte del carácter del modo puede ser nada, un asterisco ( *
), un signo de interrogación ( ?
) o un símbolo de intercalación ( ^
). Esto indica shasum
el modo con el que se generó el hash. (Nota: ningún carácter, que representa el modo de texto, es shasum
el valor predeterminado).
La ruta de archivo parte, es el camino real para el archivo que desea comprobar.
Entonces, aquí hay un ejemplo de la vida real que compara un archivo de descarga de MAMP en particular con su supuesto valor SHA-256 . Se *
requería el carácter de modo para que esta verificación funcionara:
shasum -a 256 -c <<< 'f05ede012b8a5d0e7c9cf17fee0fa1eb5cd8131f3c703ed14ea347f25be11a28 *MAMP_MAMP_PRO_5.2.pkg'
Nota: el resultado de este comando (para mi archivo de ejemplo) es:
OKAY:
MAMP_MAMP_PRO_5.2.pkg: OK
o
HA FALLADO:
MAMP_MAMP_PRO_5.2.pkg: FALLO
shasum: ADVERTENCIA: 1 suma de comprobación calculada NO coincide
shasum -c <<< '7cb77378a0749f2a9b7e09ea62ffb13febf3759f *sample.txt'
devuelve el mensaje *sample.txt: FAILED open or read
. Sin el asterisco, sample.txt: OK
. Todavía no he podido encontrar la base del uso del asterisco en otros lugares. ¿Podrías aclarar?
--binary
opción)? Desde la página del manual: "Al verificar, la entrada debe ser una salida anterior de este programa. El modo predeterminado es imprimir una línea con suma de verificación, un carácter que indica el tipo ( *
para binario,` `para texto, U
para UNIVERSAL, ^
para BITS, ?
para portátil) y el nombre de cada ARCHIVO ". Entonces, ¿los caracteres entre la suma de verificación y el nombre de archivo dependen del modo establecido cuando se creó la suma de verificación?