Qual è il modo migliore per memorizzare una password svn crittografata su Ubuntu Server?


8

ciao,

Ho Ubuntu Server che esegue un server Subversion. Sto eseguendo il client sulla stessa macchina tramite SSH e vorrei che il client svn ricordasse la mia password, ma non la memorizzasse come testo in chiaro. Guardando qui vedo due metodi: gnome-keyring e kwallet. Dato che non sto usando un desktop manager, sono un po 'diffidente nel cercare di usare uno di questi. Eventuali suggerimenti? Sarebbe ok (o addirittura funzionerebbe) usare una delle due app che ho citato?

TIA

Risposte:


9
  1. Puoi eseguire Gnome-keyring o Kwallet sul computer remoto. Ciascuno è disponibile in due componenti, un demone e una GUI.

    • È possibile eseguire l'applicazione GUI sul computer remoto se si esegue ssh con X forwarding. Solo perché è un "server" non significa che non è possibile installare applicazioni GUI su di esso. Non importa se si esegue l'ambiente desktop corrispondente o meno, le applicazioni non necessitano di un ambiente desktop specifico per l'esecuzione.

    • Puoi controllare Kwallet dalla riga di comando qdbus, anche se non è una buona idea in questo caso specifico perché dovresti scrivere la tua password in chiaro su una riga di comando, e questo può essere ficcato dagli altri utenti. Vedi anche questa risposta SU .

    • C'è un'associazione python sia per Gnome-keyring che per Kwallet (pacchetti python-keyring-gnomee python-keyring-kwallet); potresti scrivere un piccolo script in pitone per controllarli. In effetti ce n'è già uno per Gnome-keyring: gkeyring .

    • Se la password del tuo portachiavi è uguale alla password di accesso, puoi installarla libpam-keyringe il tuo portachiavi verrà automaticamente sbloccato quando esegui l'accesso. Tuttavia, ciò richiede l'accesso con una password anziché una coppia di chiavi.

  2. Se stai eseguendo Gnome-keyring o Kwallet localmente, puoi inoltrarli tramite ssh, con un po 'di lavoro. Usano socket Unix, che ssh non può inoltrare. Ma è possibile utilizzare socatinoltra i socket Unix ai socket TCP localmente e viceversa sulla macchina remota:

    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 &
    

    Questo può essere automatizzato con piccoli script di shell su ogni lato e una RemoteForwardlinea in ~/.ssh/config. In teoria, dovresti essere in grado di accedere al portachiavi gnome dalla macchina remota. Tuttavia, ho provato ad accedervi con il cavalluccio marino e non ha nemmeno provato a connettermi $GNOME_KEYRING_SOCKET; Non so perché e non so se svn sarebbe in grado di accedere al portachiavi.

  3. È possibile memorizzare la password svn su un file system crittografato. Esistono diverse opzioni ; Penso che il modo più semplice per andare avanti sia encfs. Configurazione iniziale:

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

    Flusso di lavoro normale:

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

    Questo metodo ha la mia preferenza per diversi motivi:

    • Sia la configurazione iniziale che il normale flusso di lavoro sono molto semplici.
    • Non importa da dove si accede, in particolare non è necessario disporre di un server X locale e utilizzare X forwarding su ssh.
    • Un filesystem crittografato è più versatile di un portachiavi (sebbene sia meno conveniente per l'uso del portachiavi, ma nel caso svn non importa).
    • L'unico strumento non onnipresente di cui hai bisogno è encfs (che richiede FUSE) ed è confezionato per Ubuntu.

Più di quanto avrei potuto sperare in una risposta, grazie! Proverò il terzo approccio e riferirò indietro.
Andy,

Risposta molto completa.
questo. Il

È possibile salvare la sovversione se ~ / .subversion / auth è vuoto / inesistente? Altrimenti, il 3 ° approccio è un po 'pericoloso se si dimentica di eseguire prima encfs.
unhammer,

@unhammer Con questo approccio, se il filesystem encfs non è montato, allora ~/.subversion/authè un collegamento simbolico penzolante. In tal caso, sovversione ti dice che memorizzerà la tua password (se non hai disattivato quella notifica) ma non la memorizza da nessuna parte (testata con svn 1.6.6). Quindi non c'è rischio con il terzo approccio.
Gilles 'SO- smetti di essere malvagio' il

aha, ho provato prima senza il collegamento simbolico, ma ora vedo che funziona un collegamento simbolico a una cartella all'interno della cartella crittografata, grazie per
averlo chiarito

0

gpg crittografa un file con la password dentro, ma poi avrai bisogno di una passphrase per questo (e non perdere la chiave privata!).

Immagino che potresti controllare in svn la chiave privata e che avrai ancora bisogno della passphrase per usarla, ma l'intera configurazione sembra un po 'strana.

perché hai bisogno di farlo?


Non sto cercando un modo generico per crittografare, ma un modo che si collega bene con SVN. Quando ho usato SVN su Ubuntu dekstop non c'è stato un problema, quindi presumo che abbia usato gnome-keyring. Presumo di nuovo che gnome-keyring non sia installato sul server Ubuntu, ed è per questo che c'è il problema. Al momento posso controllare le cose, ma ricevo un avviso che posso solo memorizzare la password non crittografata. Vedi il link che ho dato per maggiori dettagli. Grazie.
Andy,

Ho chiarito la spiegazione sopra, hth.
Andy,

Mi piacerebbe amare da usare ~ / .authinfo.gpg con il formato standard per netrc SVN, e hanno gpg gestire la crittografia, ma purtroppo che sembra che sarebbe bisogno di un po 'più di installazione rispetto alla soluzione encfs. Non sembra che svn consenta archivi di password arbitrari definiti dall'utente.
unhammer,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.