Synopsis
L'installation de svn avec prise en charge des trousseaux et l'installation de l'application Collabnet keyring_tool sont déjà effectuées pour nos serveurs Linux.
1) Configurez le client SVN pour utiliser le trousseau de clés:
1.1) Modifier ~ / .subversion / config
[auth]
password-stores = gnome-keyring
1.2) Modifier ~ / .subversion / serveurs
[global]
store-passwords = yes
store-plaintext-passwords = no
2) Créez un trousseau de clés pour votre mot de passe. Vous serez invité à créer un nouveau mot de passe pour déverrouiller le trousseau de clés; cela peut être tout ce que vous souhaitez:
keyring_tool --create=svn
3) Définissez le nouveau trousseau de clés par défaut:
keyring_tool --setdef=svn
4) Dans .bash_profile ou .bash_login (en supposant que vous utilisez bash comme terminal)
if [ -e /usr/bin/gnome-keyring-daemon ]; then
if [ ! -z "`kill -0 $GNOME_KEYRING_PID 2>&1`" ]; then
# Create dbus transport link for SVN to talk to the keyring.
eval `dbus-launch --sh-syntax`
# Start the keyring daemon.
# The use of export here captures the GNOME_KEYRING_PID, GNOME_KEYRING_SOCK
# env values echoed out at startup.
export `/usr/bin/gnome-keyring-daemon`
fi
fi
5) Dans .bash_logout
# Kill the message bus established for SVN / Keyring communication
if [ ! -z "`kill -0 $DBUS_SESSION_BUS_PID 2>&1`" ]; then
kill $DBUS_SESSION_BUS_PID > /dev/null 2>&1
fi
# Kill the Gnome Keyring Daemon prior to logout.
if [ ! -z "`kill -0 $GNOME_KEYRING_PID 2>&1`" ]; then
kill $GNOME_KEYRING_PID > /dev/null 2>&1
fi
Contexte
J'ai rencontré un problème similaire en essayant d'établir un moyen sans tracas pour garantir l'accès utilisateur autorisé à certains dépôts SVN au travail. Fondamentalement, nous avons dû forcer la vérification des informations d'identification à chaque fois qu'un utilisateur accède au serveur, donc même la commande svn update nécessiterait une authentification. Il est clair que le stockage des mots de passe en texte clair était sorti.Ainsi, avec un peu de recherche, j'ai utilisé le gnome-keyring comme un moyen de harceler notre base d'utilisateurs avec des demandes d'authentification constantes tout en gardant les utilisateurs non autorisés hors des référentiels, ils ne devraient pas avoir accès à la vue.
Une grande partie de notre travail quotidien se fait via des tunnels ssh dans un serveur RedHat sans support X, j'ai donc dû trouver un moyen de contourner le support X11. Après quelques recherches, j'ai réussi à trouver le chemin ici:
Matériel d'origine
http://support.wandisco.com/index.php?/Knowledgebase/Article/View/362/17/how-to-setup-encrypted-svn-password-storage-using-gnome-keyring-in-an-ssh -session
La clé ici utilise le Collabnet keyring_tool pour créer un trousseau de clés sans le client gnome-keyring-manager et établir le lancement de dbus vous-même plutôt que de laisser SVN gérer la configuration. SVN utilise DBUS pour se connecter au démon gnome-keyring-daemon et affecter l'authentification globale. En démarrant et en supprimant manuellement la session dbus avec la syntaxe -sh, vous évitez d'essayer de vous connecter à un client X au démarrage de dbus. Si vous démarrez simplement le démon gnome-keyring-daemon et essayez d'utiliser SVN, il vous demandera toujours votre mot de passe de trousseau mais vous demandera également vos informations d'identification SVN. Le dbus échouera lorsque SVN essaiera de le démarrer en raison de l'absence d'un client X; apparemment, SVN n'utilise aucun indicateur spécial lors du démarrage du dbus.
--login
option (non documentée?) Est assez utile, bien que je ne veuille certainement pas conserver mon mot de passe non haché dans un script ou le mettre sur une ligne de commande. lire en mode sans écho à partir d'un script (non-shell-language) qui transmet ensuite cette entrée au démon généré serait probablement un bon moyen de le faire. Je ne devrais avoir à démarrer ce processus qu'une fois par démarrage, il est donc logique de taper le mot de passe; J'ai juste besoin de pouvoir le faire sur la ligne de commande plutôt que via la boîte de dialogue GTK.