Sicurezza SVN + SSH


9

Uso snv + ssh con autenticazione basata su chiave. In questo momento affinché uno dei miei utenti svn acceda al repository tramite Subversion, devo impostare i file di repository in modo che siano leggibili e scrivibili sul filesystem per quegli utenti.

Voglio impedire agli utenti di essere in grado di eliminare il database dei repository quando accedono al server tramite ssh, ma sono ancora in grado di effettuare il checkout e il commit del codice.

Pensi su come posso farlo?

Risposte:


4

Per accedere a un URL svn + ssh il client svn avvia un'istanza svnserve usando "ssh -q user @ host svnserve -t" e parla con quell'istanza tramite stdin / stdout.

Se i tuoi utenti necessitano del normale accesso SSH, puoi comunque impedire loro di accedere al repository limitando l'accesso a un utente (chown -R svnserve: svnserve repo; chmod -R g-rwx, o-rwx repo) e sostituendo il comando svnserve con questo programma wrapper setuid / setgid svnserve .


10

In un ambiente utente condiviso, consiglierei di configurare un vero server Subversion ( svnserveo tramite Apache). In questo ambiente, i singoli utenti non necessitano affatto dell'accesso ai file del repository perché tutto l'accesso ai file avviene tramite l'account utente del processo del server.

Il libro Subversion contiene una sezione sulla scelta della configurazione del server che può essere d'aiuto. Da quella sezione (enfasi sulla mia):

Se disponi di un'infrastruttura fortemente basata su account SSH e se i tuoi utenti dispongono già di account di sistema sul tuo server, ha senso distribuire una soluzione svnserve-over-SSH. Altrimenti, non raccomandiamo ampiamente questa opzione al pubblico. È generalmente considerato più sicuro che i tuoi utenti accedano al repository tramite account (immaginari) gestiti da svnserve o Apache, piuttosto che da account di sistema completi.



2

Vedo due possibili direzioni per attaccare questo problema:

  • fornire un accesso limitato alla shell, ad esempio gli utenti possono utilizzare svn solo con i propri account (potrebbe essere necessario un altro account se l'accesso alla shell è richiesto anche per altri scopi) - Ho trovato alcuni riferimenti interessanti che cercano su google svnonly . Nota: non li ho provati io.
  • migrare a sovversione su https, aggiungendo certificati client. Ho visto persone discutere di questo, ma non l'ho mai fatto da solo. Unico inconveniente: richiede la distribuzione dei certificati client oltre alle chiavi ssh.

1

concordo con Greg e Olaf - vai per l'accesso https. Sto usando una tale configurazione da un po 'di tempo e non vedo davvero alcun aspetto negativo.

otterrai un ulteriore vantaggio del controllo di accesso dettagliato all'interno del repository, in modo da poterne rendere alcune parti di sola lettura e alcune completamente inaccessibili per gli utenti selezionati.

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.