Comment générer une clé gpg sans interaction avec l'utilisateur?

13

J'ai trouvé dans la méthode https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html#Unattended-GPG-key-generation pour générer des clés gpg sans interaction avec l'utilisateur, mais ce n'est pas le cas semblent fonctionner.

Mon script est:

#!/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: [email protected]
    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

Quand je l'exécute, cela montre:

=$ ./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'

Mais alors ça se bloque.

Lorsque je vérifie, en attendant, l'arborescence ps pour cet utilisateur, je vois:

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

Dans ~ / .gnupg / gpg.conf, il n'est pas fait mention d'agent, et je n'ai aucune idée de ce qu'il essaie de faire.

Les fichiers foo.pub/foo.sec sont générés dans le répertoire home, mais sont vides.

Qu'est-ce que je rate? Comment générer la clé sans aucune sorte d'interaction utilisateur?

Versions:

  • gpg (GnuPG) 2.0.26
  • libgcrypt 1.6.2
eijeze
la source

Réponses:

4

Il est probable que vous manquiez d'entropie. La génération de clés nécessite beaucoup de nombres aléatoires de très haute qualité; sans l'activité de l'utilisateur pour fournir un caractère aléatoire de haute qualité à l'ordinateur, le pool d'entropie est épuisé par la génération et le processus de génération se bloque simplement, en attendant que le pool se remplisse.

Vos choix, par ordre croissant de satisfaction, sont

  1. reconfiguration de gpg pour utiliser le générateur de nombres pseudo-aléatoires non bloquants, ce qui serait très imprudent (bien que voir ci-dessous),

  2. utiliser une solution logicielle pour dériver plus d'entropie de l'état du système existant (le noyau est notoirement conservateur quant à la quantité d'entropie qu'il est prêt à dériver de l'état du système, en particulier lorsque cet état n'a pas d'entrée humaine directe, par exemple les synchronisations CPU ou NIC); comme vous l'avez souligné, hasged est l'une de ces solutions, ou

  3. fournir à l'ordinateur une autre source physique d'entropie de haute qualité. Des appareils comme la clé entropique ou le OneRNG peuvent répondre à cette exigence (je n'ai aucun lien avec l'un ou l'autre produit, sauf que je possède une clé entropique, et j'en suis très satisfait).

Edit : mzhaase attire mon attention dans un commentaire sur cet article sur / dev / urandom vs / dev / random (pour lequel merci beaucoup, c'est un excellent article!) Et conteste mon aversion urandompour la création de clés. En fait, l'article ne dit pas que les deux sources sont équivalentes et note que

/ Dev / urandom de Linux vous donne heureusement des nombres pas si aléatoires avant que le noyau n'ait même eu la chance de recueillir l'entropie. C'est quand? Au démarrage du système, démarrage de l'ordinateur.

C'est-à-dire qu'après le démarrage, tant que le urandomPRNG n'a pas été initialisé avec une entropie suffisante, il est vraiment dangereux de l'utiliser pour la génération de clés. Cela peut prendre un certain temps, en particulier sur un serveur sans surveillance et sans tête, et nous ne savons pas quand le seuil a été atteint, car le système ne nous le dit pas explicitement.

Maintenant, si /dev/randomje suis prêt à émettre des chiffres, je peux raisonnablement en déduire que le pool d'entropie est suffisamment profond pour urandomavoir été correctement initialisé. Mais si je dois vérifier le /dev/randomblocage avant chaque utilisation de urandom(ce qui étant donné que je génère des clés moins souvent que je redémarre, c'est probablement le cas), je pourrais aussi bien utiliser les chiffres de /dev/randompour générer mes clés.

Chapelier Fou
la source
2
C'est / était le problème. Ajout d'un démon haché, et maintenant il fonctionne très bien - génération de clés en ~ 0.7s.
eijeze
Que les PRNG ne soient pas «aussi bons» est un mythe. En fait, / dev / random et / dev / urandom utilisent le même PRNG. Vous n'avez pas besoin d'un vrai hasard pour les algorithmes qui ne sont sécurisés que par des calculs (et ni / dev / random ni / dev / urandom ne peuvent réellement vous donner un vrai hasard: vous devez mesurer des choses réellement aléatoires pour cela). La seule cryptographie qui nécessite un vrai caractère aléatoire est des algorithmes sécurisés sur le plan de l'information comme le tampon à usage unique. Ce lien en parle en détail: 2uo.de/myths-about-urandom
mzhaase
@mzhaase bizarrement, je suis tombé sur ce lien et je l'ai lu plus tôt cette semaine. Je modifierai ma réponse ci-dessus pour refléter l'article, bien que je ne sois pas entièrement d'accord avec lui. Je note également que mon système, bizarrement, obtient probablement un vrai caractère aléatoire /dev/random(et donc des nombres hautement imprévisibles de /dev/urandompresque tout le temps), parce que j'ai un périphérique matériel qui utilise un tunnel quantique pour générer une entropie physiquement attachée à mon serveur (voir au dessus).
MadHatter
1
hasged fonctionne bien, la clé est générée en 1 sec. Installez juste apt-get, puis lancez: haveged
waza123
@ waza123 bon point, mais sans doute celui qui a déjà été fait par eijeze deux ans auparavant (regardez le premier commentaire ci-dessus).
MadHatter
2

J'ai trouvé qu'il y a quelques changements simples qui font fonctionner votre script. J'ai également inclus quelques tests afin qu'une fois la clé créée, elle sera automatiquement testée.

J'ai également supprimé le mot de passe afin que les tests clés puissent être automatisés.

#!/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: [email protected]
    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 [email protected] 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 [email protected] keydetails

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

A travaillé cela dans le cadre de la génération de clés pour une installation d'application automatisée. L'installation et le démarrage du package ' rngd ' pour générer entroy résoudra votre problème. simple à installer et à utiliser.

Voici le code .

  • Démarre rngd ( /dev/hwrandompar défaut, mais modifiable) pour fournir une source d'entropie
  • Copie un modèle simple (remplacez l'e-mail et le nom du modèle jinja par ce que vous voulez)
  • génère une clé en utilisant gpg
  • l'importe dans le trousseau de clés local
xddsg
la source
Dans l'exemple de code fourni urandomest utilisé comme source, ce qui est déconseillé. 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 utilise /dev/hwrandompar défaut et est modifiable. Voir la page de manuel.
xddsg
À droite, je disais que dans le code que vous avez lié, il est explicitement utilisé urandomet que cela est déconseillé.
keyneom
-1

En voici un que vous pourriez utiliser mais je recommanderais d'exécuter ce script dans un nouveau terminal afin de ne pas affecter votre actuel. Ce script continuera de générer l'entropie en gardant la machine occupée et coincée dans une boucle infinie jusqu'à ce qu'un utilisateur quitte le script. Aucune interaction utilisateur n'est nécessaire avant la génération de clés. Tout ce que le script fait est de répertorier les fichiers pour toujours.

Cela peut prendre quelques minutes (parfois 10+) à générer en fonction de votre machine et de la taille de la clé, mais il est agréable de ne pas avoir à interagir avec.

#!/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
Entropie
la source
Faire une recherche sur un système de fichiers ne génère pas une source d'entropie vraiment sécurisée car son comportement est prévisible et reproductible.
Joffrey