Essayer de créer des clés GPG qui seront utilisées pour un référentiel apt hébergé sur ma boîte Centos7. J'ai créé un nouvel utilisateur "apt", puis j'ai essayé de créer les clés, mais à la toute fin, il indique que j'ai besoin d'une phrase de passe, mais se ferme ensuite instantanément en indiquant annulé par l'utilisateur. Non, ce n'était pas le cas !
Depuis, j'ai répété avec succès ces mêmes étapes racine et comme nom d'utilisateur standard qui se trouve être dans le groupe roues.
Deux questions :
- Est-ce une bonne idée d'utiliser différentes clés gpg pour différentes utilisations telles que ce référentiel apt, et les clés doivent-elles être créées en tant que root ?
- Pourquoi ne puis-je pas créer de clé gpg pour cet utilisateur ? Dois-je d'abord créer une autre clé pour cet utilisateur ?
Merci
[[email protected] ~]$ gpg --gen-key
gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 1y
Key expires at Thu 12 Jul 2018 04:32:05 PM UTC
Is this correct? (y/N) y
GnuPG needs to construct a user ID to identify your key.
Real name: somename
Email address: [email protected]
Comment:
You selected this USER-ID:
"somename <[email protected]>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.
gpg: cancelled by user
gpg: Key generation canceled.
[[email protected] ~]$
Réponse acceptée :
En ce qui concerne l'erreur "annulé par l'utilisateur":GnuPG essaie de s'assurer qu'il lit la phrase secrète directement depuis le terminal, et non (par exemple) depuis stdin. Pour ce faire, il tente d'ouvrir directement le tty. Malheureusement, les autorisations de fichiers gênent - le périphérique tty appartient à l'utilisateur sous lequel vous vous connectez. Ainsi, seuls cet utilisateur et cette racine peuvent l'ouvrir. GnuPG semble signaler l'erreur de manière incorrecte, indiquant que vous avez annulé (alors qu'en fait, une autorisation a été refusée).
Quant à savoir si vous devriez avoir une clé distincte pour le référentiel :oui. Plusieurs raisons me viennent à l'esprit :
- Un référentiel peut être géré par plusieurs personnes. Tous auront besoin d'accéder à la clé. Vous ne voulez évidemment pas leur donner accès à votre clé personnelle.
- Le logiciel traitant les nouveaux packages aura besoin d'accéder à la clé. Pour de nombreux référentiels, cela signifie que vous devez conserver la clé disponible sur une machine connectée à Internet. Cela nécessite un niveau de sécurité inférieur à celui que vous auriez idéalement sur votre clé personnelle.
- Si vous traitez les téléchargements automatiquement, vous devrez peut-être même stocker la clé sans mot de passe. Évidemment, la sécurité diminue.
- En cas de compromission de votre clé personnelle, il est agréable de n'avoir qu'à révoquer celle-ci. Idem avec la compromission de la clé du référentiel. Cela rend la révocation d'une clé compromise moins chère.
Il est assez normal d'utiliser votre clé personnelle pour signer la clé du référentiel.
En ce qui concerne l'exécution de la génération de clés en tant que root :pas idéal (n'exécutez pas les choses en tant que root sans bonne raison), mais ce n'est probablement pas vraiment un problème.