Jak najlepiej przechowywać zaszyfrowane hasło svn na serwerze Ubuntu?


8

Cześć,

Mam Ubuntu Server z serwerem subversion. Używam klienta na tym samym komputerze przez SSH i chciałbym, aby klient svn pamiętał moje hasło, ale nie przechowywał go jako zwykłego tekstu. Patrząc tutaj widzę dwie metody: gnome-keyring i kwallet. Ponieważ nie korzystam z menedżera pulpitu, jestem nieco ostrożny, próbując użyć jednego z nich. Jakieś sugestie? Czy używanie jednej z dwóch aplikacji, o których wspomniałem, byłoby w porządku (a nawet działało)?

TIA

Odpowiedzi:


9
  1. Możesz uruchomić Gnome-keyring lub Kwallet na zdalnym komputerze. Każdy składa się z dwóch komponentów: demona i GUI.

    • Możesz uruchomić aplikację GUI na zdalnym komputerze, jeśli uruchomisz ssh z X przekazywaniem. To, że jest to „serwerowa” maszyna, nie oznacza, że ​​nie można na niej instalować aplikacji GUI. Nie ma znaczenia, czy używasz odpowiedniego środowiska pulpitu, czy nie, aplikacje nie potrzebują określonego środowiska pulpitu do uruchomienia.

    • Możesz kontrolować Kwallet za pomocą wiersza poleceń qdbus, chociaż w tym konkretnym przypadku nie jest to dobry pomysł, ponieważ musisz wpisać hasło w postaci jawnego tekstu w wierszu polecenia, a inni użytkownicy mogą to zrobić. Zobacz także tę odpowiedź SU .

    • Istnieje powiązanie Pythona zarówno dla Gnome-keyring, jak i Kwallet (pakiety python-keyring-gnomei python-keyring-kwallet); możesz napisać mały skrypt Pythona, aby je kontrolować. W rzeczywistości istnieje już jeden dla Gnome-keyring: gkeyring .

    • Jeśli twoje hasło jest takie samo jak hasło logowania, możesz je zainstalować, libpam-keyringa Twój klucz zostanie automatycznie odblokowany po zalogowaniu. Wymaga to jednak zalogowania się przy użyciu hasła zamiast pary kluczy.

  2. Jeśli korzystasz z Gnome-keyring lub Kwallet lokalnie, możesz przesłać je przez ssh, przy odrobinie pracy. Używają gniazd Unix, których ssh nie może przekazać. Ale możesz użyć socatprzekaźnika gniazd Unix do gniazd TCP lokalnie i odwrotnie na zdalnym komputerze:

    while true; do socat TCP-LISTEN:22007 UNIX-CONNECT:"$GNOME_KEYRING_SOCKET"; done &
    ssh -R22007:localhost:22007 remote.example.com
    export GNOME_KEYRING_SOCKET="$HOME/.gnome-keyring-socket"
    while true; do socat UNIX-LISTEN:"$GNOME_KEYRING_SOCKET" TCP4:localhost:22007; done &
    

    Można to zautomatyzować za pomocą małych skryptów powłoki po każdej stronie i RemoteForwardlinii ~/.ssh/config. Teoretycznie powinieneś mieć wtedy dostęp do kluczy gnome ze zdalnego komputera. Próbowałem jednak uzyskać do niego dostęp za pomocą konika morskiego i nawet nie próbowałem się z nim połączyć $GNOME_KEYRING_SOCKET; Nie wiem dlaczego i nie wiem, czy svn miałby dostęp do kluczy.

  3. Możesz przechowywać swoje hasło svn w zaszyfrowanym systemie plików. Istnieje kilka opcji ; Myślę, że najprostszym sposobem na rozpoczęcie jest encfs. Początkowe ustawienia:

    sudo aptitude install encfs
    encfs ~/.passwords.encrypted ~/.passwords
    mv ~/.subversion/auth ~/.passwords/svn-auth
    ln -s ../.passwords/svn-auth ~/.subversion/auth
    

    Normalny przepływ pracy:

    encfs ~/.passwords.encrypted ~/.passwords
    ... work ...
    fusermount -u ~/.passwords
    

    Ta metoda ma moje preferencje z kilku powodów:

    • Zarówno początkowa konfiguracja, jak i normalny przepływ pracy są bardzo proste.
    • Nie ma znaczenia skąd się logujesz, w szczególności nie musisz mieć lokalnego serwera X i używać przekazywania X przez ssh.
    • Zaszyfrowany system plików jest bardziej wszechstronny niż brelok do kluczy (chociaż jest mniej wygodny w użyciu, ale w przypadku svn nie ma to znaczenia).
    • Jedynym nie wszechobecnym narzędziem, którego potrzebujesz, jest plik encfs (który wymaga FUSE) i jest spakowany dla Ubuntu.

Więcej niż mogłem oczekiwać w odpowiedzi, dzięki! Spróbuję trzeciego podejścia i zdam raport.
Andy,

Bardzo kompletna odpowiedź.
this.josh

Czy jest możliwe spowodowanie zwolnienia subversion, jeśli ~ / .subversion / auth jest pusty / nie istnieje? W przeciwnym razie trzecie podejście jest nieco niebezpieczne, jeśli najpierw zapomnisz uruchomić kodowanie.
młot

@unhammer Przy takim podejściu, jeśli system plików encfs nie jest zamontowany, to ~/.subversion/authjest wiszące dowiązanie symboliczne. W takim przypadku subversion mówi ci, że będzie przechowywać twoje hasło (jeśli nie wyłączyłeś tego powiadomienia), ale tak naprawdę nie przechowuje go nigdzie (testowane z svn 1.6.6). Tak więc nie ma ryzyka z trzecim podejściem.
Gilles „SO- przestań być zły”

aha, najpierw próbowałem bez dowiązania symbolicznego, ale teraz widzę, że dowiązanie symboliczne do folderu w zaszyfrowanym folderze działa, dziękuję za wyjaśnienie :-)
unhammer

0

gpg zaszyfruj plik za pomocą hasła, - ale wtedy będziesz potrzebował do tego hasła (i nie zgub klucza prywatnego!).

Myślę, że możesz sprawdzić w svn klucz prywatny, a także nadal potrzebujesz hasła, aby go użyć, ale cała konfiguracja wydaje się nieco dziwna.

dlaczego musisz to zrobić?


Nie szukam ogólnego sposobu szyfrowania, ale sposób, który ładnie pasuje do SVN. Kiedy użyłem SVN na Ubuntu dekstop, nie było problemu, więc przypuszczam, że używa kluczy gnome. Przypuszczam, że gnome-keyring nie jest zainstalowany na serwerze Ubuntu i dlatego jest problem. Obecnie mogę się rejestrować, ale dostaję ostrzeżenie, że mogę przechowywać tylko hasło niezaszyfrowane. Zobacz link, który podałem, aby uzyskać więcej informacji. Dzięki.
Andy,

Wyjaśniłem powyższe wyjaśnienie, hth.
Andy,

Ja uwielbiam do użytku ~ / .authinfo.gpg ze standardowym formacie netrc dla SVN i mieć gpg obsługiwać szyfrowanie, ale niestety to, że wydaje się, że to wymaga nieco więcej ustawień niż roztwór encfs. Wygląda na to, że svn nie pozwala na przechowywanie dowolnych haseł zdefiniowanych przez użytkownika.
młot
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.