Jak zapisać hasło podczas korzystania z Subversion z konsoli

Zastanawiałem się, czy istnieje sposób na zapisanie mojego hasła Subversion podczas wykonywania svnoperacji z konsoli. Konsola to jedyna opcja, jaką mam. Kiedy próbuję wykonać jakąkolwiek akcję Subversion, np svn commit. Za każdym razem pyta o hasło do konta. Czy jest sposób, aby jakoś zapisać to hasło, aby nie musieć go za każdym razem ponownie wpisywać?

W ~/.subversion/config, prawdopodobnie masz store-passwords = no. Zmień je na yes(lub po prostu zakomentuj, ponieważ domyślnie jest na tak), a następnym razem, gdy podasz Subversion swoje hasło, powinno je zapisać.

Możesz chcieć upewnić się, że właściciel i uprawnienia ~/.subversion/configsą poprawne (brak dostępu publicznego lub grupowego; 600).

To zależy od używanego protokołu. Jeśli używasz SVN + SSH, klient SVN nie może zapisać twojego hasła, ponieważ nigdy go nie dotyka - klient SSH prosi o to bezpośrednio. W takim przypadku możesz użyć klucza SSH i agenta ssh, aby uniknąć ciągłych monitów. Jeśli używasz protokołu svnserve lub HTTP (S), klient SSH obsługuje Twoje hasło i może je zapisać.

Spróbuj wyczyścić .subversionfolder w katalogu domowym i spróbuj ponownie zatwierdzić. Powinien poprosić o podanie hasła, a następnie zapytać, czy chcesz zapisać hasło.

Musiałem edytować ~/.subversion/servers. Ustawiłem store-plaintext-passwords = yes(nie było wcześniej). To załatwiło sprawę. Można to jednak uznać za niepewne.

Zwróć uwagę na następujący akapit z ~/.subversion/serverspliku:

Zarówno „store-passwords”, jak i „store-auth-creds” można teraz określić w pliku „server” w katalogu konfiguracyjnym. Wszystko, co określono w tej sekcji, jest zastępowane ustawieniami określonymi w pliku „serwerów”.

Dotyczy to przynajmniej SVN w wersji 1.6.12. Pamiętaj więc, aby edytować plik serwerów również wtedy, gdy zastępuje ~/.subversion/config.

Jeśli używasz svn + ssh , możesz skopiować swój publiczny klucz ssh na zdalną maszynę:

ssh-copy-id user@remotehost

Dla mnie (użytkownika Maca) problem polegał na tym, że w pęku kluczy był już zapisany wpis dla moich poświadczeń, ale prawa dostępu były nieprawidłowe.

Usunięcie wpisu w aplikacji łańcucha kluczy, a następnie ponowne utworzenie go za pomocą svn rozwiązało problem.

Żadna z tych wspaniałych odpowiedzi nie działała dla mnie przy nowej instalacji Ubuntu. Zamiast tego wskazówka z tej odpowiedzi załatwiła sprawę.

Musiałem zezwolić na „proste” przechowywanie haseł, ustawiając to puste w ~/.subversion/config:

password-stores =

Nie było istniejącego ustawienia, więc bycie pustym jest znaczące.

Było to oprócz:

store-passwords = yes

w ~/.subversion/servers.

Używanie zwykłego tekstu może nie być najlepszym wyborem, jeśli hasło jest kiedykolwiek używane jako coś innego.

Popieram zaakceptowaną odpowiedź, ale nie zadziałała - z bardzo konkretnego powodu: chciałem użyć albo kwalletalbo gnome-keyringmagazynu haseł. Próbowałem zmienić ustawienia, we wszystkich czterech plikach:

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

Nawet po tym, jak wszystko było ustawione tak samo, z password-storesi nazwą KWallet (domyślna może być źle, prawda?), Nie działała i ciągle pytała o hasło. Pliki w ~/.subversionmają uprawnienia 600.

Cóż, w tym momencie możesz spróbować sprawdzić jedną prostą rzecz:

which svn

Jeśli dostaniesz:

/usr/bin/local/svn

wtedy możesz podejrzewać z dużym prawdopodobieństwem, że ten klient został zbudowany ze źródła, lokalnie, przez twojego administratora (którym możesz być Ty, jak w moim przypadku).

Subversion to paskudna bestia do kompilacji , bardzo łatwa do przypadkowego zbudowania bez obsługi HTTP lub - jak w moim przykładzie - bez obsługi zaszyfrowanych magazynów haseł (potrzebujesz albo Gnome, albo KDE, i to dużo!). Ale ./configureskrypt ci tego nie powie, a otrzymasz mniej funkcjonalne svnpolecenie.

W takim przypadku możesz wrócić do klienta, który został dostarczony z dystrybucją, zwykle w formacie /usr/bin/svn. Wadą jest to, że prawdopodobnie będziesz musiał ponownie sprawdzić kopie robocze, ponieważ nie ma svn downgradepolecenia. W każdym razie możesz skonsultować się z Linusem Torvaldsem, co należy myśleć o Subversion;)

Aby dodać do odpowiedzi Heatha: Wygląda na to, że Subversion 1.6 domyślnie wyłączył przechowywanie haseł, jeśli nie może przechowywać ich w postaci zaszyfrowanej. Możesz zezwolić na przechowywanie niezaszyfrowanych haseł, jawnie ustawiając password-stores =(czyli pustą wartość) w ~/.subversion/config.

Aby sprawdzić, którego magazynu haseł używa Subversion, zajrzyj do ~/.subversion/auth/svn.simple. Zawiera kilka plików, każdy z tabelą skrótów z prostym kodowaniem klucz / wartość. W svn:realmstringkażdym pliku określa, dla której dziedziny ten plik jest przeznaczony. Jeśli plik ma

K 8
passtype
V 6
simple

następnie przechowuje hasło w postaci zwykłego tekstu gdzieś w tym pliku, we K 8 passwordwpisie. W przeciwnym razie próbuje użyć jednego ze skonfigurowanych plików password-stores.

Wszystkie wymienione tutaj metody nie działają dla mnie. Zbudowałem Subversion ze źródeł i dowiedziałem się, że muszę uruchomić konfigurację, --enable-plaintext-password-storageaby obsługiwać tę funkcję.

Aby podkreślić, co Tomasz Gandor i Domain powiedzieli o posiadaniu odpowiedniej wersji svn i że została ona skompilowana, aby umożliwić przechowywanie haseł w postaci zwykłego tekstu, musisz zweryfikować, co masz:

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

Przeciw:

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

The following authentication credential caches are available:

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

Gdy zobaczysz, że twoja wersja svn została włączona do przechowywania haseł w postaci zwykłego tekstu, zastosuj wszystkie pozostałe odpowiedzi tutaj.

Używam klienta TortoiseSVN w systemie Windows i dla mnie ustawienie parametru store-passwords jako yes w %USERPROFILE%\AppData\Roaming\Subversion\confignie pomaga w przechowywaniu hasła.

Hasło zostało pomyślnie zapisane po usunięciu tego folderu (na wypadek zmiany nazwy):

%USERPROFILE%\AppData\Roaming\Subversion\auth

Środowisko:

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

Niestety odpowiedzi nie rozwiązały problemu z pytaniem o hasło do ssh + svn z chronionym kluczem prywatnym. Po kilku badaniach znalazłem:

ssh-add

narzędzie, jeśli masz komputer z systemem Linux. Upewnij się, że masz zapisane klucze /home/username/.ssh/i wpisz to polecenie w terminalu.