« Koji/SigulInstall » : différence entre les versions

De TartareFR
Aller à la navigation Aller à la recherche
 
(37 versions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
=Sigul Overview=
== Vue d'ensemble ==


Sigul is a package signing server, which aids in signing RPM's either multiple, or single files. All keys reside solely on the sigul server, no user has access to any of the private or public keys. All communication with the server is done through the sigul bridge, it acts as the gateway between the client, and server. This isolates the server, preventing any unwanted access from outside sources other than the bridge. The sigul client once configured allows users to sign rpm's with keys created on the sigul server, by sending commands first to the bridge, which then relays to the server.
<class>Sigul</class> est une suite logicielle pour un serveur de signature, qui peut signer les RPMs ou de simple ou multiples fichiers. Toutes les clés [[Security/OpenGPG|GPG]] sont stockés uniquement sur le serveur <class>Sigul</class> (Sigul server), et donc aucun utilisateur n'a accès à aucune clé publique ou privée. Toutes les communications avec le serveur passent par le pont <class>Sigul</class> (Sigul bridge) qui agit comme une passerelle entre le client et le serveur. Cela isole le serveur et interdit tout accès extérieur autre que depuis le pont. Le client <class>Sigul</class>, une fois configuré, autorise les utilisateurs à signer les RPMs avec les clés créées (ou importées) sur le serveur <class>Sigul</class>, en envoyant des commandes au pont, qui lui se chargera de transmettre au serveur.
[[Fichier:SigulArch.svg|441px|centré|vignette|Architecture de Sigul]]
{{Admon/bug|<class>Sigul</class> sur les systèmes el6|<class>Sigul</class> a un bug récurrent<ref>https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=894019</ref> sur les systèmes el6 et a besoin de travailler avec le paquet <package>gnupg1</package> au lieu du paquet par défaut <package>gnupg2</package>.


=Installation=
Il faut modifier le fichier <path>/usr/share/sigul/settings.py</path>
<pre>gnupg_bin = "/usr/bin/gpg1"</pre>


This part is very very easy {{Admon/smiley|:)}}
Le paquet <package>sigul</package> du dépôt B2PWeb intègre déjà les modifications pour travailler avec <package>gnupg1</package>.}}
[root@bridge] # yum install seagul


=Sigul Bridge Setup=
== Installation ==


What the bridge does: The bridge acts as the central gateway for sigul. The bridge is the only component which speaks to the server, if you are issuing any server bound commands from the client, your actually sending them to the bridge which in turn fires them off to the server, recieves the reply, and sends that back to the client. The bridge also functions as the gateway for Koji, when signing packages from a koji instance, the bridge speaks to the kojihub with authentication by way of a Proxy user, such as Kojiweb. We will be getting into the koji side of things a bit more later in this doc.
Rien de plus simple, on installe via [[RPM/UsingYum|yum]], puis on créé l'arborescence nécessaire aux composants de <class>Sigul</class>  {{Admon/smiley|:)}}


To begin setup, we have generate the certs which will be used for all sigul systems to authenticate between eachother. The bridge will be used as the CA for internal sigul communications.
La création de l'arborescence est rendue nécessaire par le fait d'installer le pont et le serveur sur le même système (chose qui n'est pas recommandée pour des raisons de sécurité)
{{Admon/warning|Be sure to remember all your NSS Password| FAS is Fedora account system, so no need for a personnal sigul server}}
<syntaxhighlight lang="bash">
yum install sigul
su - sigul -s /bin/bash -c 'mkdir /var/lib/sigul/{bridge,server}'
</syntaxhighlight>
{{Admon/tip|Modification permanente pour l'utilisateur sigul|Il peut être pratique de fixer le shell pour l'utilisateur sigul afin de simplifier les commandes d'administrations
<syntaxhighlight lang="bash"># usermod -s /bin/bash sigul</syntaxhighlight>
De même, on peut fixer définitivement les variables utilisées dans l'installation en ajoutant au fichier <path>~/.bash_profile</path> de l'utilisateur sigul
<pre>
bridge_dir=/var/lib/sigul/bridge
server_dir=/var/lib/sigul/server
export bridge_dir
export server_dir


{| class="wikitable"
gpgagent=$(ps aux | grep gpg | grep sigul | grep -v grep | wc -l)
|+ Récapitulatif des mots de passe
[ ${gpgagent} -eq 0 ] && gpg-agent --homedir=/var/lib/sigul/server --daemon --use-standard-socket 1>/dev/null 2>&1
| style="border:white 0;background-color:white;" |
</pre>
! Bridge
}}
! Server
{{Admon/note|FAS|FAS est le système de compte de Fedora, nous n'avons pas besoin de FAS pour un système <class>Sigul</class> personnel.}}
! Client
{{Admon/warning|Mot de passe NSS| Il faut impérativement se rappeler tous les mots de passes utilisés ici.}}
|-
! NSS Certificate DB
| bridgepasswd
| serverpasswd
| clientpasswd
|-
! PKCS12 Certificate
| XXXXXXXXXXXX
| server
| client
|-
! Administrator User
| XXXXXXXXXXXX
| XXXXXXXXXXXX
| ght1vtt9
|}
== Operations with sigul account ==


All following commands must be done '''with sigul account'''
== Firewall ==
[root@bridge] # su - sigul -s /bin/bash
{{Admon/tip|Set shell for user sigul permanently|<pre>[root@bridge] # usermod -s /bin/bash sigul</pre>}}


Create an NSS database on the bridge, to hold the certificate information
* Le pont <class>Sigul</class>  doit pouvoir communiquer avec le serveur <class>Sigul</class> ( default: TCP port 44333 )
<pre>
* Tous les clients <class>Sigul</class> doivent pouvoir communiquer avec le pont <class>Sigul</class> ( default: TCP port 44334 )
[sigul@bridge] $ mkdir -p /var/lib/sigul/{bridge,server}
 
[sigul@bridge] $ bridge_dir=/var/lib/sigul/bridge
Naturellement, Le pont peut avoir des accès plus restrictifs ( autorisation de quelques adresses IP )
</pre>
* Pour le pont<syntaxhighlight lang="bash">iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 44334 -j ACCEPT</syntaxhighlight>
* Pour le serveur (une seule adresse autorisée)<syntaxhighlight lang="bash">iptables -A INPUT -s 192.168.0.148/32 -p tcp -m state --state NEW -m tcp --dport 44333 -j ACCEPT</syntaxhighlight>
 
== Mise en place du pont ==
 
Le pont agit en tant que passerelle centrale su système <class>Sigul</class>. C'est le seul composant qui dialogue avec le serveur, c'est à dire que les commandes clientes pour le serveur vont être envoyées au pont, qui les relayera au serveur, recevra la réponse et la redistribuera au client. Le pont agit en tant que passerelle pour [[Koji]] pour la signature des paquets, le pont dialogue avec le [[Koji/Installation#Pr.C3.A9sentation|Hub Koji]] avec l’authentification d'un utilisateur Proxy, comme Kojiweb. La partie sur la liaison entre <class>Sigul</class> et <class>Koji</class> est [[Koji/SigulInstall#Configuration_de_Sigul_pour_koji|ici]].
 
Pour démarrer la mise en place, on doit générer les certificats qui seront utilisés pour authentifier les différent composants du système <class>Sigul</class> entre eux. Le pont sera utilisé comme Autorité de Certification pour les communications internes du système <class>Sigul</class>.
 
=== Opérations avec le compte sigul ===
 
* Comme toutes '''les commandes de cette partie doivent être lancées par l'utilisateur sigul''', on va donc devenir cet utilisateur<syntaxhighlight lang="bash"># su - sigul</syntaxhighlight>
* Définition du répertoire de destination<syntaxhighlight lang="bash">bridge_dir=/var/lib/sigul/bridge</syntaxhighlight>
* Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable ''$bridge_dir''<syntaxhighlight lang="bash">certutil -d $bridge_dir -N</syntaxhighlight>
* Génération de l'autorité de certification (CA: Certificate Authority) qui sera utilisée par tous les composants <class>Sigul</class><syntaxhighlight lang="bash">certutil -d $bridge_dir -S -n sigul-ca -s 'CN=Sigul CA' -t CT,, -x -v 120</syntaxhighlight>
* Génération d'un certificat pour le pont<br>Le champs CN doit être le nom complet de l'hôte (fqdn) sur lequel le pont est hebergé<syntaxhighlight lang="bash">certutil -d $bridge_dir -S -n sigul-bridge-cert -s 'CN=koji.b2pweb.com' -c sigul-ca -t u,, -v 120</syntaxhighlight>
 
=== Opérations avec le compte root ===
 
Il est temps de configurer le pont en éditant le fichier <path>/etc/sigul/bridge.conf</path>


Generate a new NSS database for the bridge at the location of the bridge_dir variable
<pre>
<pre>
[sigul@bridge] $ certutil -d $bridge_dir -N</pre>
[bridge]
bridge-cert-nickname: sigul-bridge-cert
client-listen-port: 44334
server-listen-port: 44333
max-rpms-payload-size: 10737418240


Generate the CA (Certificate Authority) certificate, to be used accross all sigul components
[koji]
koji-config: ~/.koji/config


CN must be the full qualified domain name of the server where bridge is hosted.
[daemon]
<pre>
unix-user: sigul
[sigul@bridge] $ certutil -d $bridge_dir -S -n sigul-ca -s 'CN=Sigul CA' -t CT,, -x -v 120
unix-group: sigul
</pre>


Create a certificate for the bridge
[nss]
<pre>
nss-dir: /var/lib/sigul/bridge
[sigul@bridge] $ certutil -d $bridge_dir -S -n sigul-bridge-cert -s 'CN=bridge.b2pweb.com' -c sigul-ca -t u,, -v 120
nss-password: bridgensspasswd
</pre>
</pre>


== Operations with root account ==
=== Test ===
Now it is time to configure the bridge, edit '''with the root account''' the config at <path>/etc/sigul/bridge.conf</path>
* You can leave most things at their default such as ports, or fas-account settings, if using FAS authentication.
* Under the [NSS] section you can set nss-password: yournsspass
* The default configuration assumes you set up a separate "sigul" user and group. Remove the [daemon] section if you want the bridge to run as the invoking user.
* If you use a separate user and group issue: chown sigul:sigul $bridge_dir/*.db


After editing the config and setting up the certs, it is time for a test drive issue the following
Lancement en mode debug, les logs se trouvant dans le fichier <path>/var/log/sigul_bridge.log</path>
[root@bridge] # sigul_bridge -v -v
<syntaxhighlight lang="bash">sigul_bridge -v -v</syntaxhighlight>
This will start the bridge in DEBUG mode, and all information will be logged in <path>/var/log/sigul_bridge.log</path>


Check the log file after starting sigul, if there are no errors you are good to go.
Vérification du fichier journal et s'il n'y a pas d'erreur, on peut continuer.
{{Admon/note|You should see the first log message in <path>/var/log/sigul_bridge.log</path>
{{Admon/note|Le premier message du fichier <path>/var/log/sigul_bridge.log</path> doit être
<pre>2011-11-24 16:41:42,214 DEBUG: Waiting for the client to connect</pre>}}
<pre>2011-11-24 16:41:42,214 DEBUG: Waiting for the client to connect</pre>}}
      
      
Stop the sigul_bridge CRTL-C  
Arrêt du pont sigul CRTL-C  


Now we can start the service, and enable daemon start at boot
=== Démarrage ===


for fedora >= 16
On peut maintenant lancer le deamon et activer son démarrage automatique au démarrage.
[root@bridge] # systemctl start sigul_bridge.service
[root@bridge] # systemctl enable sigul_bridge.service


for fedora < 16
'''systemd'''
[root@bridge] # service sigul_bridge start
<syntaxhighlight lang="bash">
[root@bridge] # chkconfig sigul_bridge on
systemctl start sigul_bridge.service
systemctl enable sigul_bridge.service
</syntaxhighlight>
'''sysVinit'''
<syntaxhighlight lang="bash">
service sigul_bridge start
chkconfig sigul_bridge on
</syntaxhighlight>
 
== Mise en place du serveur ==


=Sigul Server Setup=
Le serveur est complètement isolé du reste du monde. Toutes les communications depuis l'extérieur doivent être interdites, exception faite des communications avec le pont. De même, les communications sortantes doivent être restreintes au pont pour un maximum de sécurité. Il faut s'assurer qu'aucun accès exterieur est possible (même web). Il détient toutes les clés pour signer les RPMs, et donc aucun utilisateur ne doit avoir accès directement aux clés, le serveur est le seul système qui connait les clés.


What the server does: The server is completley cutoff from the rest of the world, It should be firewalled off except for incoming ports from the bridge, and should only be able to speak to the bridge, for max security, ensure it has no external access from other machines or even the web. It hold's all of the key files used for signing the RPMS, so no other users will have access to the key files, the server is the only system that knows the keys.
=== Opérations préalables sur le pont avec l'utilisateur sigul ===
* Export de l'autorité de certification dans le fichier <path>sigulca.p12</path><syntaxhighlight lang="bash">pk12util -d $bridge_dir -o sigulca.p12 -n sigul-ca</syntaxhighlight>
* Copie du fichier <path>sigulca.p12</path> sur le serveur <class>Sigul</class>
* Destruction de l'export<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>


To begin setup, we have to follow a similar process to the bridge with NSS, except that we will import the CA cert generated on the bridge, not generate a new one.
=== Opérations avec l'utilisateur sigul ===


== Operations with sigul account ==
* Comme toutes '''les commandes de cette partie doivent être lancées par l'utilisateur sigul''', on va donc devenir cet utilisateur<syntaxhighlight lang="bash"># su - sigul</syntaxhighlight>
* Définition du répertoire de destination<syntaxhighlight lang="bash">server_dir=/var/lib/sigul/server</syntaxhighlight>
* Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable ''$server_dir''<syntaxhighlight lang="bash">certutil -d $server_dir -N</syntaxhighlight>
* Import de l'autorité de certification (CA: Certificate Authority)<syntaxhighlight lang="bash">pk12util -d $server_dir -i sigulca.p12</syntaxhighlight><syntaxhighlight lang="bash">certutil -d $server_dir -M -n sigul-ca -t CT,,</syntaxhighlight>
* Génération d'un certificat pour le serveur<br>Le champs CN doit être le nom complet de l'hôte (fqdn) sur lequel le serveur est hebergé<syntaxhighlight lang="bash">certutil -d $server_dir -S -n sigul-server-cert -s 'CN=koji.b2pweb.com' -c sigul-ca -t u,, -v 120</syntaxhighlight>
* Suppression de l'export de l'autorité de certification<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>
{{Admon/bug|Répertoire racine de gnupg|Bien que la configuration de sigul puisse être éditée,
<pre>_default_storage_path = '/var/lib/sigul/server'
default_gnupg_home = os.path.join(_default_storage_path, 'gnupg')
</pre>
il faut quand même rajouter un lien symbolique à la racine du répertoire personnel de sigul.
<pre>
cd /var/lib/sigul
ln -s /var/lib/sigul/server/gnupg gnupg
</pre>}}


Create the NSS database on the server, to hold the certificate information '''with the user sigul account'''
=== Opérations avec l'utilisateur root ===


First we set the location where sigul resides on the system
Il est temps de configurer le serveur en éditant le fichier <path>/etc/sigul/server.conf</path>.
<pre>
<pre>
[sigul@server] $ server_dir=/var/lib/sigul/server
[server]
[sigul@server] $ certutil -d $server_dir -N
bridge-hostname: koji.didier-linux.eu
</pre>
bridge-port: 44333
max-file-payload-size: 1073741824
max-memory-payload-size: 1048576
max-rpms-payload-size: 10737418240
server-cert-nickname: sigul-server-cert
signing-timeout: 60


This will generate a new NSS database for the server at the location of the server_dir variable
[database]
database-path: /var/lib/sigul/server/server.sqlite


Import the CA (Certificate Authority) certificate, generated earlier on the bridge
[gnupg]
=== ON THE BRIDGE as user sigul ===
gnupg-home: /var/lib/sigul/server/gnupg
<pre>
gnupg-key-type: DSA
[sigul@bridge] $ pk12util -d $bridge_dir -o sigulca.p12 -n sigul-ca
gnupg-key-length: 1024
</pre>
gnupg-subkey-type: ELG-E
This file should now be copied over to the server and deleted from the bridge afterwards
gnupg-subkey-length: 2048
gnupg-key-usage: sign
passphrase-length: 64


=== ON THE SERVER as user sigul ===
[daemon]
The sigul CA certs should now be imported
unix-user: sigul
<pre>
unix-group: sigul
[sigul@server] $ pk12util -d $server_dir -i sigulca.p12
[sigul@server] $ rm sigul.p12
[sigul@server] $ certutil -d $server_dir -M -n sigul-ca -t CT,,
</pre>


CN must be the full qualified domain name of the server where sigul server is hosted.
[nss]
<pre>
nss-dir: /var/lib/sigul/server
[sigul@server] $ certutil -d $server_dir -S -n sigul-server-cert -s 'CN=server.b2pweb.com' -c sigul-ca -t u,, -v 120
nss-password: **********
</pre>
</pre>


== Operations with root account ==
On va maintenant créer la base de données pour que le serveur y stocke les informations à propos des utilisateurs et des clés
<syntaxhighlight lang="bash">sigul_server_create_db</syntaxhighlight>


Now it is time to configure the server, edit the config at /etc/sigul/server.conf '''with root account'''<br>Note the default ports. Edit at least bridge-hostname and the [nss] section. The default configuration assumes you set up a separate "sigul" user and group; remove the [daemon] section if you want the server to run as the invoking user.
On va ajouter l'administrateur initial. Celui-ci doit déjà exister localement sur le système.  
<syntaxhighlight lang="bash">sigul_server_add_admin</syntaxhighlight>


Now to create the database for the server which will hold all user and key entries issue the following * AS ROOT
=== Test ===
<pre>[root@server] # sigul_server_create_db</pre>


Next Add the initial administrator
Lancement en mode debug, les logs se trouvant dans le fichier <path>/var/log/sigul_server.log</path>
<pre>[root@server] # sigul_server_add_admin</pre>
<syntaxhighlight lang="bash">sigul_server -v -v</syntaxhighlight>


After all is configured, it's time for a test drive
Vérification du fichier journal et s'il n'y a pas d'erreur, on peut continuer.
 
Start the server in DEBUG mode, and all information will be logged in <path>/var/log/sigul_server.log</path>
<pre>[root@server] # sigul_server -v -v</pre>
Check the log file after starting sigul server, if there are no errors you are good to go.
{{Admon/note|You should see the first log message in <path>/var/log/sigul_server.log:</path>
{{Admon/note|You should see the first log message in <path>/var/log/sigul_server.log:</path>
<pre>2011-11-24 16:36:42,154 DEBUG: Waiting for a request</pre>}}
<pre>2011-11-24 16:36:42,154 DEBUG: Waiting for a request</pre>}}
   
Arrêt du pont sigul CRTL-C


Now we can start the service, and enable daemon start at boot
=== Démarrage ===


for fedora >= 16
On peut maintenant lancer le deamon et activer son démarrage automatique au démarrage.
[root@server] # systemctl start sigul_server.service
[root@server] # systemctl enable sigul_server.service


for fedora < 16
'''systemd'''
[root@server] # service sigul_server start
<syntaxhighlight lang="bash">
[root@server] # chkconfig sigul_server on
systemctl start sigul_server.service
 
systemctl enable sigul_server.service
=Sigul Client Setup=
</syntaxhighlight>
'''sysVinit'''
<syntaxhighlight lang="bash">
service sigul_server start
chkconfig sigul_server on
</syntaxhighlight>


What the client does: The client is simply that, a client, it has certs necessary for it to be authenticated with the sigul bridge to issue commands as the sigul admin, to the server. All client commands are sent to bridge which in turn talks to either koji or the server depending on what the clients request is.
== Mise en place du Client ==


To begin setup, we have to follow a similar process to the bridge with NSS, except that we will import the CA cert generated on the bridge, not generate a new one.
Le client doit pouvoir s'authentifier sur le pont avec des certificats pour pouvoir envoyer des commandes à celui-ci.
   
=== ON THE BRIDGE as user sigul ===
$ pk12util -d $bridge_dir -o sigulca.p12 -n sigul-ca
This file should now be copied over to the client and deleted from the bridge afterwards


=== ON THE BRIDGE as root ===
=== Opérations préalables sur le pont avec l'utilisateur sigul ===
Copy <path>/var/lib/sigul/sigulca.p12</path> to the user home, and change owner of it.
# cp /var/lib/sigul/sigulca.p12 /home/USER/
# chown USER /home/USER/sigulca.p12


=== ON THE CLIENT as your users ===
* Export de l'autorité de certification dans le fichier <path>sigulca.p12</path><syntaxhighlight lang="bash">pk12util -d $bridge_dir -o sigulca.p12 -n sigul-ca</syntaxhighlight>
* Copie du fichier <path>sigulca.p12</path> sur le client <class>Sigul</class> et modification du propriétaire sur celui-ci
* Destruction de l'export<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>


Create the NSS database on the client, to hold the certificate information issue the following
=== Opérations sur le client avec l'utilisateur root ===


$ client_dir=~/.sigul
Edition du fichier <path>/etc/sigul/client.conf</path>
$ mkdir $client_dir
<pre>
$ certutil -d $client_dir -N
[client]
 
bridge-hostname: koji.didier-linux.eu
Import the CA (Certificate Authority) certificate, generated earlier on the bridge
bridge-port: 44334
$ pk12util -d $client_dir -i sigulca.p12
client-cert-nickname: sigul-client-cert
$ rm sigulca.p12
server-hostname: koji.didier-linux.eu
$ certutil -d $client_dir -M -n sigul-ca -t CT,,


Generate the authentication certificate for the client.
[koji]
koji-config: ~/.koji/config


CN must be the user account
$ certutil -d $client_dir -S -n sigul-client-cert -s 'CN=didier' -c sigul-ca -t u,, -v 120
== Operations with root account ==
Configure the client, edit the config at <path>/etc/sigul/client.conf</path>
* You can leave most things set as default except for the following:
* bridge-hostname and server-hostname be sure to change those to match the hostnames of each of those machines.
* under [ NSS] user-name set this to the value of the admin user your setup on the server previously
* If you wish to avoid entering an NSS password upon issuing each command, issue vim <path>~/.sigul/client.conf</path> and add the following lines:
<pre>
[nss]
[nss]
nss-password: Your NSS PASS
nss-dir: ~/.sigul
</pre>
</pre>


After configuring your client, issue a test client command in DEBUG mode as follows:
=== Opérations sur le client avec l'utilisateur qui utilisera Sigul ===
# sigul -v -v list-users
{{Admon/note|This should return a list of users on the server, at this point it should only really display the one admin user created before. For more commands issue sigul --help-commands for a full list}}


Now, we can create a key or import an existing key.
* Définition du répertoire de destination<syntaxhighlight lang="bash">client_dir=~/.sigul</syntaxhighlight>
== create a new key ==
* Création de celui-ci<syntaxhighlight lang="bash">mkdir $client_dir</syntaxhighlight>
Create an initial key once you are able to issue commands to sigul, issue the following:
* Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable ''$client_dir''<syntaxhighlight lang="bash">certutil -d $client_dir -N</syntaxhighlight>
$ sigul new-key -h
* Import de l'autorité de certification (CA: Certificate Authority)<syntaxhighlight lang="bash">pk12util -d $client_dir -i sigulca.p12</syntaxhighlight><syntaxhighlight lang="bash">certutil -d $client_dir -M -n sigul-ca -t CT,,</syntaxhighlight>
This will output the options that can be used with the key creation, use the ones you want, and generate the key.*
* Génération d'un certificat pour le serveur<br>Le champs CN doit être le login de l'utilisateur pour le système <class>Sigul</class><syntaxhighlight lang="bash">certutil -d $client_dir -S -n sigul-client-cert -s 'CN=root' -c sigul-ca -t u,, -v 120</syntaxhighlight>
$ sigul new-key --name-real='Service Reseaux et Systemes' --name-comment='SRS' --name-email='srs@b2pweb.com'--key-admin didier srs
* Suppression de l'export de l'autorité de certification<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>
* Copie du fichier de configuration générale des clients <path>/etc/sigul/client.conf</path> dans son répertoire personnel <path>~/.sigul/client.conf</path><syntaxhighlight lang="bash">cp /etc/sigul/client.conf ~/.sigul/client.conf</syntaxhighlight>
* Édition du fichier <path>~/.sigul/client.conf</path> pour insérer le mot de passe de l'utilisateur dans la section [nss].<syntaxhighlight lang="bash">nss-password: Your NSS PASS</syntaxhighlight>


{{Admon/note|Generating enough entropy|Generating the key requires a lot of Entropy on the server, so issue some commands to keep server busy and help it generate faster, usually a simple <pre>find / > /dev/null 2>&1</pre> will generate enough for it to take about 2 minutes to generate the key.}}
=== Test ===
Test avec une commande sigul pour valider le bon fonctionnement de toute la chaine
sigul list-users


== Import an existing key ==
On peut maintenant utiliser pleinement <class>Sigul</class>.
$ sigul import-key 'Service Reseaux et Systemes' ~/.gnupg/secring.gpg


=Sigul with koji Setup=
==Sigul Client Config Script==


How it works with koji: Sigul can be used with koji to sign multiple packages in a koji instance. Provided you have your client user already configured with Koji, it's a simple matter of configuring the proxy user on sigul_bridge. When a client issues a sign command for a koji instance, the bridge is what actually queries koji on behalf of the client user, and grabs the rpm's to be signed from sigul by way of the kojiweb user. The only thing you must ensure is that your koji client user as admin privileges on the koji server, and the bridge takes care if the rest.
Ce script peut être utilisé pour mettre en place rapidement l’authentification pour un client <class>Sigul</class> quand l’authentification FAS n'est pas utilisée.
 
{{Admon/important|L'utilisateur doit déjà être créé sur le serveur|Ce script ne fait que la mise en place des certificats.}}
As ROOT on the sigul bridge, edit /etc/sigul/bridge.conf edit the koji section as follows:
[koji]
koji-config: /path/to/koji/config/file  <-- The config file should be that of koji web
 
The koji configuration file and certs can reside under any directory that sigul has atleast read privileges on. The kojiweb certificates that allow kojiweb to authenticate with koji must be copied to this directory, along with the config file which points to the koji instance, as well as the kojiweb certs needed for it to authenticate.
 
After doing the above restart the bridge, and you should now be able to pull packages from koji and sign them.
 
To test issue the following on the client, to download and RPM from koji - sign it - and store it locally - Just as a test for koji connectivity and authentication:
$ sigul sign-rpm -o signed.rpm key_name unsigned.rpm <-- key_name should be the name of the sigul key you setup previously.
   
If the above is successful, you will have an rpm named signed.rpm in the directory you are working in.
 
=Sigul Client Config Script=
 
The following is an optional script, which can be used to aide in the quick setup of sigul clients, when not using FAS Authentication:
* Note that the user must first have an account created on the sigul server, this script is solely to setup the client side certificates
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
  #!/bin/bash
  #!/bin/bash
Ligne 294 : Ligne 303 :
  #########################################\
  #########################################\
</syntaxhighlight>
</syntaxhighlight>
*If you plan to use FAS Authentication, run sigul_setup_client as the user you wish to setup.


= Next =
== Utilisation ==
Next is to use the [[Koji/SigulUsing|Sigul signing server]]
Utilisation de son [[Koji/SigulUsing|Sigul signing server]]
 
== Références ==
<references/>

Dernière version du 22 avril 2015 à 07:41

Vue d'ensemble

<class>Sigul</class> est une suite logicielle pour un serveur de signature, qui peut signer les RPMs ou de simple ou multiples fichiers. Toutes les clés GPG sont stockés uniquement sur le serveur <class>Sigul</class> (Sigul server), et donc aucun utilisateur n'a accès à aucune clé publique ou privée. Toutes les communications avec le serveur passent par le pont <class>Sigul</class> (Sigul bridge) qui agit comme une passerelle entre le client et le serveur. Cela isole le serveur et interdit tout accès extérieur autre que depuis le pont. Le client <class>Sigul</class>, une fois configuré, autorise les utilisateurs à signer les RPMs avec les clés créées (ou importées) sur le serveur <class>Sigul</class>, en envoyant des commandes au pont, qui lui se chargera de transmettre au serveur.

Architecture de Sigul
Bug.png
<class>Sigul</class> sur les systèmes el6
<class>Sigul</class> a un bug récurrent[1] sur les systèmes el6 et a besoin de travailler avec le paquet <package>gnupg1</package> au lieu du paquet par défaut <package>gnupg2</package>.

Il faut modifier le fichier <path>/usr/share/sigul/settings.py</path> 

gnupg_bin = "/usr/bin/gpg1"
Le paquet <package>sigul</package> du dépôt B2PWeb intègre déjà les modifications pour travailler avec <package>gnupg1</package>.

Installation

Rien de plus simple, on installe via yum, puis on créé l'arborescence nécessaire aux composants de <class>Sigul</class> Face-smile.png

La création de l'arborescence est rendue nécessaire par le fait d'installer le pont et le serveur sur le même système (chose qui n'est pas recommandée pour des raisons de sécurité) 

yum install sigul
su - sigul -s /bin/bash -c 'mkdir /var/lib/sigul/{bridge,server}'
Idea.png
Modification permanente pour l'utilisateur sigul
Il peut être pratique de fixer le shell pour l'utilisateur sigul afin de simplifier les commandes d'administrations 
# usermod -s /bin/bash sigul

De même, on peut fixer définitivement les variables utilisées dans l'installation en ajoutant au fichier <path>~/.bash_profile</path> de l'utilisateur sigul 

bridge_dir=/var/lib/sigul/bridge
server_dir=/var/lib/sigul/server
export bridge_dir
export server_dir

gpgagent=$(ps aux | grep gpg | grep sigul | grep -v grep | wc -l)
[ ${gpgagent} -eq 0 ] && gpg-agent --homedir=/var/lib/sigul/server --daemon --use-standard-socket 1>/dev/null 2>&1
Note.png
FAS
FAS est le système de compte de Fedora, nous n'avons pas besoin de FAS pour un système <class>Sigul</class> personnel.
Warning.png
Mot de passe NSS
Il faut impérativement se rappeler tous les mots de passes utilisés ici.

Firewall

  • Le pont <class>Sigul</class> doit pouvoir communiquer avec le serveur <class>Sigul</class> ( default: TCP port 44333 )
  • Tous les clients <class>Sigul</class> doivent pouvoir communiquer avec le pont <class>Sigul</class> ( default: TCP port 44334 )

Naturellement, Le pont peut avoir des accès plus restrictifs ( autorisation de quelques adresses IP )

  • Pour le pont
    iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 44334 -j ACCEPT
  • Pour le serveur (une seule adresse autorisée)
    iptables -A INPUT -s 192.168.0.148/32 -p tcp -m state --state NEW -m tcp --dport 44333 -j ACCEPT

Mise en place du pont

Le pont agit en tant que passerelle centrale su système <class>Sigul</class>. C'est le seul composant qui dialogue avec le serveur, c'est à dire que les commandes clientes pour le serveur vont être envoyées au pont, qui les relayera au serveur, recevra la réponse et la redistribuera au client. Le pont agit en tant que passerelle pour Koji pour la signature des paquets, le pont dialogue avec le Hub Koji avec l’authentification d'un utilisateur Proxy, comme Kojiweb. La partie sur la liaison entre <class>Sigul</class> et <class>Koji</class> est ici.

Pour démarrer la mise en place, on doit générer les certificats qui seront utilisés pour authentifier les différent composants du système <class>Sigul</class> entre eux. Le pont sera utilisé comme Autorité de Certification pour les communications internes du système <class>Sigul</class>.

Opérations avec le compte sigul

  • Comme toutes les commandes de cette partie doivent être lancées par l'utilisateur sigul, on va donc devenir cet utilisateur
    # su - sigul
  • Définition du répertoire de destination
    bridge_dir=/var/lib/sigul/bridge
  • Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable $bridge_dir
    certutil -d $bridge_dir -N
  • Génération de l'autorité de certification (CA: Certificate Authority) qui sera utilisée par tous les composants <class>Sigul</class>
    certutil -d $bridge_dir -S -n sigul-ca -s 'CN=Sigul CA' -t CT,, -x -v 120
  • Génération d'un certificat pour le pont
    Le champs CN doit être le nom complet de l'hôte (fqdn) sur lequel le pont est hebergé
    certutil -d $bridge_dir -S -n sigul-bridge-cert -s 'CN=koji.b2pweb.com' -c sigul-ca -t u,, -v 120

Opérations avec le compte root

Il est temps de configurer le pont en éditant le fichier <path>/etc/sigul/bridge.conf</path> 

[bridge]
bridge-cert-nickname: sigul-bridge-cert
client-listen-port: 44334
server-listen-port: 44333
max-rpms-payload-size: 10737418240

[koji]
koji-config: ~/.koji/config

[daemon]
unix-user: sigul
unix-group: sigul

[nss]
nss-dir: /var/lib/sigul/bridge
nss-password: bridgensspasswd

Test

Lancement en mode debug, les logs se trouvant dans le fichier <path>/var/log/sigul_bridge.log</path> 

sigul_bridge -v -v

Vérification du fichier journal et s'il n'y a pas d'erreur, on peut continuer.

Note.png
Le premier message du fichier <path>/var/log/sigul_bridge.log</path> doit être 
2011-11-24 16:41:42,214 DEBUG: Waiting for the client to connect

Arrêt du pont sigul CRTL-C

Démarrage

On peut maintenant lancer le deamon et activer son démarrage automatique au démarrage.

systemd 

systemctl start sigul_bridge.service
systemctl enable sigul_bridge.service

sysVinit 

service sigul_bridge start
chkconfig sigul_bridge on

Mise en place du serveur

Le serveur est complètement isolé du reste du monde. Toutes les communications depuis l'extérieur doivent être interdites, exception faite des communications avec le pont. De même, les communications sortantes doivent être restreintes au pont pour un maximum de sécurité. Il faut s'assurer qu'aucun accès exterieur est possible (même web). Il détient toutes les clés pour signer les RPMs, et donc aucun utilisateur ne doit avoir accès directement aux clés, le serveur est le seul système qui connait les clés.

Opérations préalables sur le pont avec l'utilisateur sigul

  • Export de l'autorité de certification dans le fichier <path>sigulca.p12</path>
    pk12util -d $bridge_dir -o sigulca.p12 -n sigul-ca
  • Copie du fichier <path>sigulca.p12</path> sur le serveur <class>Sigul</class>
  • Destruction de l'export
    rm -f sigulca.p12

Opérations avec l'utilisateur sigul

  • Comme toutes les commandes de cette partie doivent être lancées par l'utilisateur sigul, on va donc devenir cet utilisateur
    # su - sigul
  • Définition du répertoire de destination
    server_dir=/var/lib/sigul/server
  • Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable $server_dir
    certutil -d $server_dir -N
  • Import de l'autorité de certification (CA: Certificate Authority)
    pk12util -d $server_dir -i sigulca.p12

    certutil -d $server_dir -M -n sigul-ca -t CT,,
  • Génération d'un certificat pour le serveur
    Le champs CN doit être le nom complet de l'hôte (fqdn) sur lequel le serveur est hebergé
    certutil -d $server_dir -S -n sigul-server-cert -s 'CN=koji.b2pweb.com' -c sigul-ca -t u,, -v 120
  • Suppression de l'export de l'autorité de certification
    rm -f sigulca.p12
Bug.png
Répertoire racine de gnupg
Bien que la configuration de sigul puisse être éditée, 
_default_storage_path = '/var/lib/sigul/server'
default_gnupg_home = os.path.join(_default_storage_path, 'gnupg')

il faut quand même rajouter un lien symbolique à la racine du répertoire personnel de sigul. 

cd /var/lib/sigul
ln -s /var/lib/sigul/server/gnupg gnupg

Opérations avec l'utilisateur root

Il est temps de configurer le serveur en éditant le fichier <path>/etc/sigul/server.conf</path>. 

[server]
bridge-hostname: koji.didier-linux.eu
bridge-port: 44333
max-file-payload-size: 1073741824
max-memory-payload-size: 1048576
max-rpms-payload-size: 10737418240
server-cert-nickname: sigul-server-cert
signing-timeout: 60

[database]
database-path: /var/lib/sigul/server/server.sqlite

[gnupg]
gnupg-home: /var/lib/sigul/server/gnupg
gnupg-key-type: DSA
gnupg-key-length: 1024
gnupg-subkey-type: ELG-E
gnupg-subkey-length: 2048
gnupg-key-usage: sign
passphrase-length: 64

[daemon]
unix-user: sigul
unix-group: sigul

[nss]
nss-dir: /var/lib/sigul/server
nss-password: **********

On va maintenant créer la base de données pour que le serveur y stocke les informations à propos des utilisateurs et des clés 

sigul_server_create_db

On va ajouter l'administrateur initial. Celui-ci doit déjà exister localement sur le système. 

sigul_server_add_admin

Test

Lancement en mode debug, les logs se trouvant dans le fichier <path>/var/log/sigul_server.log</path> 

sigul_server -v -v

Vérification du fichier journal et s'il n'y a pas d'erreur, on peut continuer.

Note.png
You should see the first log message in <path>/var/log/sigul_server.log:</path> 
2011-11-24 16:36:42,154 DEBUG: Waiting for a request

Arrêt du pont sigul CRTL-C

Démarrage

On peut maintenant lancer le deamon et activer son démarrage automatique au démarrage.

systemd 

systemctl start sigul_server.service
systemctl enable sigul_server.service

sysVinit 

service sigul_server start
chkconfig sigul_server on

Mise en place du Client

Le client doit pouvoir s'authentifier sur le pont avec des certificats pour pouvoir envoyer des commandes à celui-ci.

Opérations préalables sur le pont avec l'utilisateur sigul

  • Export de l'autorité de certification dans le fichier <path>sigulca.p12</path>
    pk12util -d $bridge_dir -o sigulca.p12 -n sigul-ca
  • Copie du fichier <path>sigulca.p12</path> sur le client <class>Sigul</class> et modification du propriétaire sur celui-ci
  • Destruction de l'export
    rm -f sigulca.p12

Opérations sur le client avec l'utilisateur root

Edition du fichier <path>/etc/sigul/client.conf</path> 

[client]
bridge-hostname: koji.didier-linux.eu
bridge-port: 44334
client-cert-nickname: sigul-client-cert
server-hostname: koji.didier-linux.eu

[koji]
koji-config: ~/.koji/config

[nss]
nss-dir: ~/.sigul

Opérations sur le client avec l'utilisateur qui utilisera Sigul

  • Définition du répertoire de destination
    client_dir=~/.sigul
  • Création de celui-ci
    mkdir $client_dir
  • Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable $client_dir
    certutil -d $client_dir -N
  • Import de l'autorité de certification (CA: Certificate Authority)
    pk12util -d $client_dir -i sigulca.p12

    certutil -d $client_dir -M -n sigul-ca -t CT,,
  • Génération d'un certificat pour le serveur
    Le champs CN doit être le login de l'utilisateur pour le système <class>Sigul</class>
    certutil -d $client_dir -S -n sigul-client-cert -s 'CN=root' -c sigul-ca -t u,, -v 120
  • Suppression de l'export de l'autorité de certification
    rm -f sigulca.p12
  • Copie du fichier de configuration générale des clients <path>/etc/sigul/client.conf</path> dans son répertoire personnel <path>~/.sigul/client.conf</path>
    cp /etc/sigul/client.conf ~/.sigul/client.conf
  • Édition du fichier <path>~/.sigul/client.conf</path> pour insérer le mot de passe de l'utilisateur dans la section [nss].
    nss-password: Your NSS PASS

Test

Test avec une commande sigul pour valider le bon fonctionnement de toute la chaine 

sigul list-users

On peut maintenant utiliser pleinement <class>Sigul</class>.

Sigul Client Config Script

Ce script peut être utilisé pour mettre en place rapidement l’authentification pour un client <class>Sigul</class> quand l’authentification FAS n'est pas utilisée.

Important.png
L'utilisateur doit déjà être créé sur le serveur
Ce script ne fait que la mise en place des certificats.
 #!/bin/bash
 #Variables### And initial setup#######
 mkdir ~/.sigul
 client_dir=~/.sigul
 user=$(whoami)  
 ####################
 echo
 ############################Begin Certificate imports
 echo "======================="
 echo "Setting up NSS Database"
 echo "======================="
 certutil -d $client_dir -N
 echo
 echo "==================="
 echo "Downloading CA Cert"
 echo "==================="
 wget http://someurl.com/sigul/sigulca.p12 <-- Substitute with a path or url of your exported .p12
 echo
 echo "=================="
 echo "Importing CA certs"
 echo "=================="
 pk12util -d $client_dir -i sigulca.p12
 certutil -d $client_dir -M -n sigul-ca -t CT,,
 echo
 echo "======================"
 echo "Generating Client cert"
 echo "======================"
 certutil -d $client_dir -S -n sigul-client-cert -s "CN=$user" -c sigul-ca -t u,, -v 120
 echo
 echo "======================"
 #########End certificate imports########
 ########################################
 #########NSS password Saver#############
 read -p "Would you like to save your nss pass to ~/.sigul/client.conf [y/n]: " nsspasssel
 #########User Input conditional#########
 if [ $nsspasssel == "y" -o $nsspasssel == "Y" ]; then
 echo "Enter your NSS password One more time: "
 read -s nsspass
 echo "[nss]" > ~/.sigul/client.conf
 echo "nss-password: $nsspass" >> ~/.sigul/client.conf
 echo
 echo "==========="
 echo "Cleaning up"
 echo "==========="
 rm sigulca.p12
 else
 echo
 echo "==========="
 echo "Cleaning up"
 echo "==========="
 rm sigulca.p12
 fi
 #########################################\

Utilisation

Utilisation de son Sigul signing server

Références

  1. ↑ https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=894019
Récupérée de « https://wikiold.home.tartarefr.eu/index.php?title=Koji/SigulInstall&oldid=3109 »