¿Cómo generar clave gpg sin interacción del usuario?


13

Encontré en https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html#Unattended-GPG-key-generation para generar claves gpg sin interacción del usuario, pero no lo hace parece funcionar

Mi guión es:

#!/usr/bin/env bash
rm -rf .gnupg
mkdir -m 0700 .gnupg
touch .gnupg/gpg.conf
chmod 600 .gnupg/gpg.conf
tail -n +4 /usr/share/gnupg2/gpg-conf.skel > .gnupg/gpg.conf

touch .gnupg/{pub,sec}ring.gpg


cat >.gnupg/foo <<EOF
    %echo Generating a basic OpenPGP key
    Key-Type: RSA
    Key-Length: 2048
    Subkey-Type: RSA
    Subkey-Length: 2048
    Name-Real: User 1
    Name-Comment: User 1
    Name-Email: user@1.com
    Expire-Date: 0
    Passphrase: kljfhslfjkhsaljkhsdflgjkhsd
    %pubring foo.pub
    %secring foo.sec
    # Do a commit here, so that we can later print "done" :-)
    %commit
    %echo done
EOF

gpg2 --verbose --batch --gen-key .gnupg/foo

Cuando lo ejecuto, muestra:

=$ ./gen.keys.sh 
gpg: Generating a basic OpenPGP key
gpg: no running gpg-agent - starting one
gpg: writing public key to `foo.pub'
gpg: writing secret key to `foo.sec'

Pero luego simplemente se cuelga.

Cuando verifico, mientras tanto, el árbol ps para este usuario, veo:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
tstpg    22603  0.0  0.0  24108  5688 pts/9    Ss   14:59   0:00 -bash
tstpg    22624  0.0  0.0  13688  3168 pts/9    S+   14:59   0:00  \_ bash ./gen.keys.sh
tstpg    22632  0.2  0.0  27428  3676 pts/9    SL+  14:59   0:00      \_ gpg2 --verbose --batch --gen-key .gnupg/foo
tstpg    22634  0.3  0.0  18072  2884 pts/9    SL+  14:59   0:00          \_ gpg-agent --server

En ~ / .gnupg / gpg.conf no se menciona al agente, y no tengo idea de lo que está tratando de hacer.

Los archivos foo.pub/foo.sec se generan en el directorio de inicio, pero están vacíos.

¿Qué me estoy perdiendo? ¿Cómo generar la clave sin ningún tipo de interacción del usuario?

Versiones

  • gpg (GnuPG) 2.0.26
  • libgcrypt 1.6.2

Respuestas:


4

Es probable que se esté quedando sin entropía. La generación de claves requiere muchos números aleatorios de muy alta calidad; sin la actividad del usuario de proporcionar aleatoriedad de alta calidad a la computadora, el grupo de entropía se está agotando por generación, y el proceso de generación simplemente se bloquea, esperando que el grupo se vuelva a llenar.

Sus elecciones, en orden de satisfacción creciente, son

  1. reconfigurar gpg para usar el generador de números pseudoaleatorios sin bloqueo, lo que sería más imprudente (aunque ver más abajo),

  2. usando una solución de software para derivar más entropía del estado del sistema existente (el núcleo es notablemente conservador acerca de cuánta entropía está preparado para derivar del estado del sistema, particularmente donde ese estado no tiene entrada humana directa, por ejemplo, tiempos de CPU o NIC); como usted ha señalado, el refugio es una de esas soluciones, o

  3. proporcionando a la computadora otra fuente física de entropía de alto grado. Los dispositivos como Entropy Key o OneRNG pueden cumplir este requisito (no tengo conexión con ninguno de los productos, salvo que tengo una Entropy Key y estoy muy contento con ella).

Editar : mzhaase llama mi atención en un comentario a este artículo sobre / dev / urandom vs. / dev / random (¡por lo que muchas gracias, es un excelente artículo!) Y no está de acuerdo con mi aversión a usar urandompara crear claves. De hecho, el artículo no dice que las dos fuentes son equivalentes, y señala que

Linux / dev / urandom felizmente le da números no tan aleatorios antes de que el núcleo incluso tuviera la oportunidad de reunir entropía. ¿Cuando es eso? Al inicio del sistema, arranca la computadora.

Es decir, después del arranque, hasta que el urandomPRNG se haya inicializado con suficiente entropía, realmente no es seguro usarlo para la generación de claves. Eso puede llevar un tiempo, especialmente en un servidor desatendido y sin cabeza, y no sabemos cuándo se ha alcanzado el umbral, porque el sistema no nos lo dice explícitamente.

Ahora, si /dev/randomestá preparado para emitir números, puedo inferir razonablemente que el grupo de entropía es lo suficientemente profundo como urandompara haberse inicializado correctamente. Pero si tengo que verificar el /dev/randombloqueo antes de cada uso de urandom(lo cual es probable que sea el caso, dado que genero claves con menos frecuencia de lo que reinicio), también podría usar los números de /dev/randompara generar mis claves.


2
Ese es / fue el problema. Se agregó un demonio forjado, y ahora funciona bien: generación de claves en ~ 0.7s.
eijeze

Que los PRNG no sean "tan buenos" es un mito. De hecho, / dev / random y / dev / urandom usan el mismo PRNG. No requiere una aleatoriedad verdadera para algoritmos que solo sean computacionalmente seguros (y ni / dev / random ni / dev / urandom pueden realmente proporcionarle una aleatoriedad verdadera: necesita medir cosas realmente aleatorias para eso). La única criptografía que requiere una aleatoriedad verdadera son los algoritmos informativamente seguros como el pad de una sola vez. Este enlace habla sobre esto en detalle: 2uo.de/myths-about-urandom
mzhaase

@mzhaase curiosamente, me encontré con ese enlace y lo leí a principios de esta semana. Editaré mi respuesta anterior para reflejar el artículo, aunque no estoy totalmente de acuerdo con él. También noto que mi sistema, curiosamente, probablemente obtiene una aleatoriedad verdadera de /dev/random(y, por lo tanto, números muy impredecibles de /dev/urandomcasi todo el tiempo), porque tengo un dispositivo de hardware que usa túneles cuánticos para generar entropía físicamente conectada a mi servidor (ver encima).
MadHatter

1
haveged funciona bien, la clave se genera en 1 seg. Simplemente apt-get install haveged, y luego ejecute: haveged
waza123

@ waza123 buen punto, aunque podría decirse que ya fue hecho por eijeze dos años antes (mira el primer comentario anterior).
MadHatter

2

Descubrí que hay algunos cambios simples que hacen que su script funcione. También he incluido algunas pruebas para que una vez que se cree la clave se pruebe automáticamente.

También eliminé la contraseña para que las pruebas clave puedan automatizarse.

#!/usr/bin/env bash
rm -rf .gnupg
mkdir -m 0700 .gnupg
touch .gnupg/gpg.conf
chmod 600 .gnupg/gpg.conf
tail -n +4 /usr/share/gnupg2/gpg-conf.skel > .gnupg/gpg.conf

cd .gnupg
# I removed this line since these are created if a list key is done.
# touch .gnupg/{pub,sec}ring.gpg
gpg2 --list-keys


cat >keydetails <<EOF
    %echo Generating a basic OpenPGP key
    Key-Type: RSA
    Key-Length: 2048
    Subkey-Type: RSA
    Subkey-Length: 2048
    Name-Real: User 1
    Name-Comment: User 1
    Name-Email: user@1.com
    Expire-Date: 0
    %no-ask-passphrase
    %no-protection
    %pubring pubring.kbx
    %secring trustdb.gpg
    # Do a commit here, so that we can later print "done" :-)
    %commit
    %echo done
EOF

gpg2 --verbose --batch --gen-key keydetails

# Set trust to 5 for the key so we can encrypt without prompt.
echo -e "5\ny\n" |  gpg2 --command-fd 0 --expert --edit-key user@1.com trust;

# Test that the key was created and the permission the trust was set.
gpg2 --list-keys

# Test the key can encrypt and decrypt.
gpg2 -e -a -r user@1.com keydetails

# Delete the options and decrypt the original to stdout.
rm keydetails
gpg2 -d keydetails.asc
rm keydetails.asc

1

Lo resolvió como parte de la generación de claves para una instalación automatizada de aplicaciones. Instalar e iniciar el paquete ' rngd ' para generar entrada solucionará su problema. Simple de instalar y usar.

Aquí está el código .

  • Inicia rngd ( /dev/hwrandompor defecto, pero modificable) para proporcionar una fuente de entropía
  • Copia una plantilla simple (reemplaza el correo electrónico y el nombre de la plantilla jinja con lo que quieras)
  • genera una clave usando gpg
  • lo importa al llavero local

En el código de muestra proporcionado urandomse utiliza como fuente, lo que se desaconseja. wiki.archlinux.org/index.php/Rng-tools Warning: Some tutorials available in the Internet, and even early versions of rng-tools package, recommend the following line for systems without TRGN: RNGD_OPTS="-o /dev/random -r /dev/urandom" Of course, this is a really bad idea, since you are simple filling the kernel entropy pool with entropy coming from the kernel itself! If your system does not have an available TRGN consider using haveged instead. See FS#34580 for details.
keyneom

@keyneom rngd usa /dev/hwrandomde forma predeterminada y es modificable. Ver página del manual.
xddsg

Correcto, estaba afirmando que en el código que vinculaste está explícitamente usando urandomy que se desaconseja hacerlo.
keyneom

-1

Aquí hay uno que podría usar, pero recomendaría ejecutar este script en una nueva terminal para no afectar la actual. Este script continuará generando entropía al mantener la máquina ocupada y atascada en un bucle infinito hasta que un usuario salga del script. No es necesaria la interacción del usuario hasta después de la generación de claves. Todo lo que hace el script es listar archivos para siempre.

Puede demorar unos minutos (a veces más de 10) para generar dependiendo de su máquina y el tamaño de la clave, pero es bueno no tener que interactuar con ella.

#!/bin/sh

while true;
do find * / && find * / && find * / && find * / && find * / && find * / && find * / && find * / && find * /;

echo "Press ctrl+c to exit this infinite loop"
sleep 2;
done

Hacer una búsqueda en un sistema de archivos no está generando una fuente de entropía verdaderamente segura porque su comportamiento es predecible y reproducible.
Joffrey
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.