Come generare la chiave gpg senza l'interazione dell'utente?

Ho trovato in https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html#Unattended-GPG-key-generation metodo per generare chiavi gpg senza l'interazione dell'utente, ma non funziona sembra funzionare.

La mia sceneggiatura è:

#!/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

Quando lo eseguo, mostra:

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

Ma poi si blocca e basta.

Quando controllo, nel frattempo, l'albero ps per questo utente, vedo:

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

In ~ / .gnupg / gpg.conf non si fa menzione dell'agente e non ho idea di cosa stia cercando di fare.

I file foo.pub/foo.sec sono generati nella directory home, ma sono vuoti.

Cosa mi sto perdendo? Come generare la chiave senza alcun tipo di interazione dell'utente?

versioni:

• gpg (GnuPG) 2.0.26
• libgcrypt 1.6.2

È probabile che si stia esaurendo l'entropia. La generazione delle chiavi richiede molti numeri casuali di altissima qualità; senza l'attività dell'utente di fornire casualità di alta qualità al computer, il pool di entropia viene esaurito di generazione in generazione e il processo di generazione si blocca in attesa che il pool si riempia.

Le tue scelte, in ordine di crescente soddisfazione, lo sono

1. riconfigurare gpg per usare il generatore di numeri pseudocasuali non bloccanti, che sarebbe poco saggio (anche se vedi sotto),

2. usare una soluzione software per derivare più entropia dallo stato di sistema esistente (il kernel è notoriamente conservatore riguardo a quanta entropia è preparato a derivare dallo stato di sistema, in particolare laddove tale stato non ha input umani diretti, ad esempio tempistiche CPU o NIC); come hai sottolineato, hasged è una di queste soluzioni, o

3. fornire al computer un'altra fonte fisica di entropia di alto livello. Dispositivi come Entropy Key o OneRNG possono soddisfare questo requisito (non ho alcuna connessione con nessuno dei due prodotti se non possiedo una Entropy Key e ne sono molto soddisfatto).

Modifica : mzhaase attira la mia attenzione in un commento a questo articolo su / dev / urandom vs. / dev / random (per il quale molte grazie, è un articolo eccellente!) E mette in discussione la mia antipatia per l'uso urandomdi creare chiavi. In effetti, l'articolo non dice che le due fonti sono equivalenti, e osserva che

Linux / dev / urandom ti dà felicemente numeri non casuali prima ancora che il kernel abbia avuto la possibilità di raccogliere entropia. Quando è questo? All'avvio del sistema, avviare il computer.

Ciò significa che, dopo l'avvio, fino a quando il urandomPRNG non è stato inizializzato con entropia sufficiente, non è sicuro utilizzarlo per la generazione delle chiavi. Ciò potrebbe richiedere del tempo, soprattutto su un server incustodito e senza testa, e non sappiamo quando è stata raggiunta la soglia, perché il sistema non ci dice esplicitamente.

Ora, se /dev/randomè disposto a emettere numeri, posso ragionevolmente dedurre che il pool di entropia sia abbastanza profondo da urandomessere stato inizializzato correttamente. Ma se devo verificare il /dev/randomblocco prima di ogni utilizzo di urandom(che dato che genera le chiavi meno spesso del riavvio, è probabile che sia il caso), potrei anche usare i numeri /dev/randomper generare le mie chiavi.

Ho scoperto che ci sono alcune semplici modifiche che fanno funzionare il tuo script. Ho anche incluso alcuni test in modo che una volta creata la chiave verrà automaticamente testata.

Ho anche rimosso la password in modo che i test chiave possano essere automatizzati.

#!/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

Risolto questo come parte della generazione di chiavi per l'installazione automatica di un'applicazione. L'installazione e l'avvio del pacchetto ' rngd ' per generare entroy risolveranno il problema. Semplice da installare e utilizzare.

Ecco il codice .

• Inizia rngd ( /dev/hwrandomper impostazione predefinita, ma modificabile) per fornire una fonte di entropia
• Copia un modello semplice (sostituisci l'e-mail e il nome del modello jinja con quello che desideri)
• genera una chiave usando gpg
• lo importa nel portachiavi locale

Eccone uno che potresti usare ma ti consiglio di eseguire questo script in un nuovo terminale in modo da non influire su quello attuale. Questo script continuerà a generare entropia mantenendo la macchina occupata e bloccata in un ciclo infinito fino a quando un utente non esce dallo script. Nessuna interazione dell'utente è necessaria fino a dopo la generazione della chiave. Tutto lo script fa è elencare i file per sempre.

Potrebbero essere necessari alcuni minuti (a volte 10+) per generare a seconda della macchina e della dimensione della chiave, ma è bello non dover interagire con esso.

#!/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