Comment enregistrer un mot de passe lors de l'utilisation de Subversion à partir de la console
Je me demandais s'il existe un moyen de sauvegarder mon mot de passe Subversion en effectuant des opérations svn à partir de la console. La console est la seule option que j'ai. Lorsque j'essaie de faire une action Subversion, par exemple svn commit, il demande le mot de passe du compte à chaque fois. Y a-t-il un moyen de sauvegarder ce mot de passe pour que je n'aie pas à le retaper à chaque fois?
Dans ~/.Subversion/config, vous avez probablement store-passwords = no. Remplacez-le par yes (ou commentez-le simplement car sa valeur par défaut est oui) et la prochaine fois que vous donnerez votre mot de passe à Subversion, il devrait l'enregistrer.
Vous voudrez peut-être vous assurer que le propriétaire et les autorisations de ~/.Subversion/config sont corrects (pas d'accès public ou de groupe; 600).
Cela dépend du protocole que vous utilisez. Si vous utilisez SVN + SSH, le client SVN ne peut pas enregistrer votre mot de passe car il ne le touche jamais. Le client SSH vous le demande directement. Dans ce cas, vous pouvez utiliser une clé SSH et ssh-agent pour éviter les invites constantes. Si vous utilisez le protocole svnserve ou HTTP (S), le client SSH gère votre mot de passe et peut le sauvegarder.
Essayez de nettoyer votre .Subversion dans votre répertoire personnel et réessayez. Il devrait vous demander votre mot de passe, puis vous demander si vous souhaitez enregistrer le mot de passe.
Je devais éditer ~/.Subversion/servers. Je mets store-plaintext-passwords = yes _ (n'était pas auparavant). Cela a fait le tour. Cela pourrait cependant être considéré comme peu sûr.
Veuillez noter le paragraphe suivant du ~/.Subversion/servers fichier:
Les mots de passe "store-store" et "store-auth-creds" peuvent maintenant être spécifiés dans le fichier "serveurs" de votre répertoire de configuration. Tout ce qui est spécifié dans cette section est remplacé par les paramètres spécifiés dans le fichier 'serveurs'.
C'est au moins pour la version 1.6.12 de SVN. Pensez donc à éditer le fichier server également car il remplace ~/.Subversion/config.
Si vous utilisez svn + ssh, vous pouvez copier votre clé publique ssh sur la machine distante:
ssh-copy-id user@remotehost
Pour moi (utilisateur Mac), le problème était que le trousseau avait déjà une entrée stockée pour mes informations d'identification, mais les droits d'accès n'étaient pas corrects.
La suppression de l'entrée dans l'application de chaîne de clés, puis sa recréation à l'aide de svn ont résolu le problème.
Aucune de ces merveilleuses réponses n'a fonctionné pour moi sur une nouvelle installation d'Ubuntu. Au lieu de cela, un indice de this answer a fait l'affaire pour moi.
Je devais autoriser le "simple" magasin de mots de passe en définissant ce champ vide dans ~/.Subversion/config:
password-stores =
Il n'y avait pas de paramètre existant, donc être vide est significatif.
C'était en plus de:
store-passwords = yes
dans ~/.Subversion/servers.
L'utilisation de texte en clair peut ne pas être le meilleur choix si le mot de passe est utilisé autrement.
Je soutiens la réponse acceptée, mais cela n’a pas fonctionné pour moi - pour une raison très précise: je voulais utiliser soit kwallet ou gnome-keyring mot de passe stocke. J'ai essayé de modifier les paramètres, sur les quatre fichiers:
/etc/Subversion/config
/etc/Subversion/servers
~/.Subversion/config
~/.Subversion/servers
Même après que tout soit réglé de la même façon, avec password-stores et le nom de KWallet (par défaut peut-être erroné, non?) cela n'a pas fonctionné et a continué à demander un mot de passe pour toujours. Les fichiers dans ~/.Subversion avait des autorisations 600.
Eh bien, à ce stade, vous pouvez essayer de vérifier une chose simple:
which svn
Si vous obtenez:
/usr/bin/local/svn
vous pouvez alors soupçonner très probablement que ce client a été créé à partir de la source, localement, par votre administrateur (qui peut être vous-même, comme dans mon cas).
Subversion est une bête à compiler , très facile à construire accidentellement sans support HTTP, ou - comme dans mon exemple - sans support pour les magasins de mots de passe cryptés (vous besoin de fichiers de développement Gnome ou KDE, et beaucoup d’entre eux!). Mais le ./configurescript ne vous le dira pas et vous obtenez juste une commande moins fonctionnelle svn.
Dans ce cas, vous pouvez revenir au client, qui est venu avec votre distribution, généralement en /usr/bin/svn. L'inconvénient est que vous devrez probablement revérifier les copies de travail, car il n'y a pas de svn downgrade commande. Vous pouvez consulter Linus Torvalds sur quoi penser de Subversion, de toute façon;)
Malheureusement, les réponses ne résolurent pas le problème de demander un mot de passe pour ssh + svn avec une clé privée protégée. Après quelques recherches, j'ai trouvé:
ssh-add
utilitaire si vous avez un ordinateur Linux. Assurez-vous que vos clés sont stockées dans /home/username/.ssh/ et tapez cette commande sur Terminal.
J'utilise le client TortoiseSVN sous Windows et pour moi, définir le paramètre store-passwords comme étant yes dans% USERPROFILE%\AppData\Roaming\Subversion\config ne permet pas de stocker le mot de passe.
Le mot de passe a bien été enregistré après la suppression de ce dossier (juste au cas où il serait renommé):
%USERPROFILE%\AppData\Roaming\Subversion\auth
Environnement:
TortoiseSVN 1.7.11 pour Windows 7 (version 23600 - 64 bits, 2012-12-12T19: 08: 52), sous-version 1.7.8.
Pour ajouter à la réponse de Heath: Il semblerait que Subversion 1.6 soit désactivé pour stocker les mots de passe par défaut s'il ne peut pas les stocker sous forme cryptée. Vous pouvez autoriser le stockage de mots de passe non chiffrés en définissant explicitement password-stores = (c'est-à-dire à la valeur vide) dans ~/.Subversion/config.
Pour vérifier le mot de passe utilisé par le magasin Subversion, recherchez dans ~/.Subversion/auth/svn.simple. Celui-ci contient plusieurs fichiers, chacun une table de hachage avec un simple encodage clé/valeur. Le svn:realmstring dans chaque fichier identifie le domaine auquel ce fichier est destiné. Si le fichier a
K 8
passtype
V 6
simple
puis il stocke le mot de passe en texte brut quelque part dans ce fichier, dans un fichier K 8 password entrée. Sinon, il essaie d'utiliser l'un des fichiers password-stores.