Comment enregistrer le mot de passe lors de l'utilisation de Subversion depuis la console

Je me demandais s'il existe un moyen de sauvegarder mon mot de passe Subversion lors des svnopérations à partir de la console. La console est la seule option que j'ai. Lorsque j'essaye de faire une action Subversion, par exemple svn commit, il me demande le mot de passe du compte à chaque fois. Existe-t-il un moyen d'enregistrer ce mot de passe d'une manière ou d'une autre pour ne pas avoir à le retaper à chaque fois?

Dans ~/.subversion/config, vous avez probablement store-passwords = no. Changez-le en yes(ou mettez-le simplement en commentaire car il est par défaut 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/configsont 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 l'enregistrer.

Essayez d'effacer votre .subversiondossier dans votre répertoire personnel et essayez à nouveau de vous engager. Il devrait vous demander votre mot de passe, puis vous demander si vous souhaitez enregistrer le mot de passe.

J'ai dû éditer ~/.subversion/servers. J'ai mis store-plaintext-passwords = yes(n'était pas auparavant). Cela a fait l'affaire. Cela pourrait cependant être considéré comme peu sûr.

Veuillez noter le paragraphe suivant du ~/.subversion/serversfichier:

Les deux 'store-passwords' et 'store-auth-creds' peuvent maintenant être spécifiés dans le fichier 'servers' 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. Gardez donc à l'esprit de modifier également le fichier des serveurs 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 porte-clés, puis sa recréation à l'aide de svn, a 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 cette réponse a fait l'affaire pour moi.

J'ai dû autoriser le stockage de mot de passe "simple" en définissant ce vide dans ~/.subversion/config:

password-stores =

Il n'y avait aucun paramètre existant, donc être vide est significatif.

C'était en plus de:

store-passwords = yes

dans ~/.subversion/servers.

L'utilisation du texte en clair n'est peut-être pas le meilleur choix, si le mot de passe est déjà utilisé comme autre chose.

Je soutiens la réponse acceptée, mais cela n'a pas fonctionné pour moi - pour une raison très spécifique: je voulais utiliser soit kwalletou des gnome-keyringmagasins de mots de passe. J'ai essayé de changer les paramètres, sur les quatre fichiers:

/etc/subversion/config
/etc/subversion/servers
~/.subversion/config
~/.subversion/servers

Même après que tout a été défini de la même manière, avec password-storeset le nom de KWallet (la valeur par défaut peut être erronée, non?) Cela ne fonctionnait pas et continuait à demander un mot de passe pour toujours. Les fichiers dans ~/.subversionavaient 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

alors vous pouvez soupçonner avec une grande probabilité que ce client a été construit à partir des sources, localement, par votre administrateur (qui peut être vous-même, comme dans mon cas).

Subversion est une méchante 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 avez 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 svncommande moins fonctionnelle .

Dans ce cas, vous pouvez revenir au client, fourni avec votre distribution, généralement au format /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 downgradecommande. Vous pouvez consulter Linus Torvalds pour savoir quoi penser de Subversion, de toute façon;)

Pour ajouter à la réponse de Heath: Il semble que Subversion 1.6 ait désactivé le stockage des mots de passe par défaut s'il ne peut pas les stocker sous forme cryptée. Vous pouvez autoriser le stockage des mots de passe non chiffrés en définissant explicitement password-stores =(c'est-à-dire à la valeur vide) dans ~/.subversion/config.

Pour vérifier quel magasin de mots de passe subversion utilise, regardez dans ~/.subversion/auth/svn.simple. Celui-ci contient plusieurs fichiers, chacun une table de hachage avec un simple encodage clé / valeur. Le svn:realmstringdans 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 une K 8 passwordentrée. Sinon, il essaie d'utiliser l'un des fichiers password-stores.

Toutes les méthodes mentionnées ici ne fonctionnent pas pour moi. J'ai construit Subversion à partir de la source et j'ai découvert que je dois exécuter configure avec --enable-plaintext-password-storagepour prendre en charge cette fonctionnalité.

Juste pour souligner ce que Tomasz Gandor et Domain ont dit à propos de la bonne version de svn et du fait qu'elle a été compilée pour permettre le stockage des mots de passe en texte brut, vous devez vérifier ce que vous avez:

svn --version
svn, version 1.9.7 (r1800392)
...
WARNING: Plaintext password storage is enabled!
...

The following authentication credential caches are available:

* Plaintext cache in /gr/home/ffvdqb/.subversion
* GPG-Agent

Contre:

svn --version
svn, version 1.12.2 (r1863366)
...

The following authentication credential caches are available:

* Gnome Keyring
* GPG-Agent
* KWallet (KDE)

Une fois que vous voyez que votre version de svn a été activée pour le stockage des mots de passe en texte brut, appliquez toutes les autres réponses ici.

J'utilise le client TortoiseSVN sous Windows, et pour moi, définir le paramètre store-passwords sur yes in %USERPROFILE%\AppData\Roaming\Subversion\confign'aide pas à stocker le mot de passe.

Le mot de passe a été enregistré avec succès après la suppression de ce dossier (juste au cas où le changement de nom):

%USERPROFILE%\AppData\Roaming\Subversion\auth

Environnement:

Windows 7, TortoiseSVN 1.7.11 (Build 23600 - 64 bit, 2012-12-12T19:08:52), Subversion 1.7.8.

Malheureusement, les réponses n'ont pas résolu le problème de la demande de 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 /home/username/.ssh/et tapez cette commande sur le terminal.