Streszczenie
Wymagane zadania instalacji svn z obsługą kluczy i instalacji aplikacji Collabnet keyring_tool są już wykonywane dla naszych serwerów Linux.
1) Skonfiguruj klienta SVN do korzystania z kluczy:
1.1) Edycja ~ / .subversion / config
[auth]
password-stores = gnome-keyring
1.2) Edytuj ~ / .subversion / server
[global]
store-passwords = yes
store-plaintext-passwords = no
2) Utwórz brelok do hasła. Zostaniesz poproszony o utworzenie nowego hasła, aby odblokować brelok; może to być coś, co chcesz:
keyring_tool --create=svn
3) Ustaw nowy brelok jako domyślny:
keyring_tool --setdef=svn
4) W .bash_profile lub .bash_login (zakładając, że używasz bash jako terminala)
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) W .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
tło
Zetknąłem się z podobnym problemem podczas próby ustanowienia bezproblemowego sposobu zapewnienia autoryzowanemu użytkownikowi dostępu do niektórych repozytoriów SVN w pracy. Zasadniczo musieliśmy wymuszać sprawdzanie poświadczeń za każdym razem, gdy użytkownik uzyskuje dostęp do serwera, więc nawet polecenie aktualizacji svn wymagałoby uwierzytelnienia. Wykluczono przechowywanie haseł w postaci zwykłego tekstu, więc przy odrobinie badań natknąłem się na użycie klucza gnome jako sposobu na nękanie naszej bazy użytkowników ciągłymi żądaniami uwierzytelnienia, jednocześnie utrzymując nieautoryzowanych użytkowników poza repozytoriami, których nie powinni mieć dostępu do widoku.
Większość naszej codziennej pracy jest wykonywana przez tunele ssh do serwera RedHat bez obsługi X, więc musiałem znaleźć sposób na obejście obsługi X11. Po kilku poszukiwaniach udało mi się znaleźć sposób na obejście tego tutaj:
Materiał źródłowy
http://support.wandisco.com/index.php?/Knowledgebase/Article/View/362/17/how-to-setup-encrypted-svn-password-storage-using-gnome-keyring-in-an-ssh -sesja
Kluczem tutaj jest użycie Collabnet keyring_tool do stworzenia kluczy bez klienta gnome-keyring-manager i samodzielnego uruchomienia dbus, zamiast pozwalania SVN obsługiwać konfigurację. SVN używa DBUS do łączenia się z demonem gnome-keyring i wpływa na ogólne uwierzytelnianie. Ręczne uruchamianie i burzenie sesji dbus przy użyciu -sh-składni pozwala uniknąć próby połączenia się z klientem X podczas uruchamiania dbus. Jeśli po prostu uruchomisz demona gnome-keyring i spróbujesz użyć SVN, nadal poprosi cię o hasło do klucza, ale również o podanie poświadczeń SVN. Dbus zawiedzie, gdy SVN spróbuje go uruchomić z powodu braku klienta X; najwyraźniej SVN nie używa żadnych specjalnych flag podczas uruchamiania dbus.
--login
opcja (nieudokumentowana?) Jest dość przydatna, chociaż na pewno nie chciałbym przechowywać mojego nieskasowanego hasła w skrypcie ani umieszczać go w wierszu poleceń. czytanie w trybie bezechowym ze skryptu (nie w języku powłoki), który następnie przekazuje te dane wejściowe do spawnowanego demona, prawdopodobnie byłby dobrym sposobem na zrobienie tego. Powinienem musiał rozpocząć ten proces tylko raz podczas rozruchu, więc warto wpisać hasło; Muszę tylko móc to zrobić w wierszu poleceń zamiast w oknie dialogowym GTK.