Remote-Subversion-Server mit SSH absichern

At long last gucke auch ich mir an, wie ich meine Quelltexte einer Versionierung unterwerfen könnte. Allerdings wäre ich nicht ich, wenn ich nicht besondere Anforderungen hätte. Genauer gesagt wollte ich eine zweigeteilte Absicherung haben. Ich wollte, dass der Server des Versionierungssystems nur per Localhost nutzbar ist und dass man, um dort hin zu kommen, sich erst einmal per SSH verbinden muss.

Mein Blick wanderte zuerst in Richtung Git, da es derzeit ein ziemlich gehyptes System ist. Wahrscheinlich jeder aus dem IT-Bereich ist schon mal über ein Github-Repository gestolpert. Allerdings missfiel mir, wie Git den Zugriff regelt. Man kann machen, dass ein Nutzer sich einfach per SSH verbindet und dann lokal mit Git arbeitet. Dazu benötigt er aber Zugriff auf die schlussendlichen Dateien. Man kann einen Git-Server verwenden, der dann jedoch keine Authentisierung bietet. Oder man arbeitet per HTTP/S.

Mir fehlte dort eine Zwischenschritt. Also sah ich mir das wahrscheinlich bekannteste Versionsverwaltungstool Subversion an. Auch hier gibt es - wie bei Git - die Möglichkeit, lokal per SSH, über ein eigenes Protokoll oder über HTTP/S zu arbeiten. Jedoch mit einem Unterschied: Das eigene Protokoll bietet eine Authentisierung! Super! Damit könnte ich meine angestrebte Lösung etablieren! Also ging ich wie folgt vor:

Als erstes installierte ich mir Subversion auf meinem Remote-Rechner. Unter Debian geht das ziemlich einfach über folgende zwei Befehle:

1
2
sudo aptitude update
sudo aptitude install subversion

Danach erstellte ich erst einmal einen Ordner, in dem später sämtliche Daten von Subversion liegen würden:

1
sudo mkdir /subversion

Anschließend legte ich einen Nutzer an, unter dem der Subversion-Server später laufen würde. Dieser muss sich nicht einloggen können und sein Homeverzeichnis kann ruhig das Subversion-Verzeichnis sein. Ein Passwort benötigt der Nutzer ebenfalls nicht (achtet darauf, dass die Shell "/usr/sbin/nologin" in der Liste der verfügbaren Shells in der Datei "/etc/shells" enthalten ist):

1
sudo adduser --home /subversion --shell /usr/sbin/nologin subversion

Nun kann das Subversion-Verzeichnis dem Subversion-Nutzer übertragen werden:

1
2
sudo chown subversion:subversion /subversion
sudo chmod 750 /subversion

Anschließend können wir das erste Mal den eigentlichen Subversion-Server starten. Wir führen ihn als Daemon unter dem gerade angelegten Nutzer aus und setzen sein Rootverzeichnis auf das von uns angelegte Subversion-Directory. Darüber hinaus sagen wir noch, dass er nur auf die IP-Adresse von Localhost hören soll, damit er von außen nicht erreichbar ist:

1
sudo su -m subversion -c "svnserve --daemon --root=/subversion --listen-host 127.0.0.1 --listen-port 3690"

Das gute an dieser Konfiguration ist, dass so kein normaler Subversion-Nutzer Zugriff auf den Inhalt des Subversion-Ordners haben können muss. Damit ist eine Manipulation des Repositories auf Dateiebene nicht möglich. Der einzige, der so Zugriff haben können muss, ist der Administrator, der ja zum Beispiel neue Repositories anlegt. So, wie im nächsten Schritt zum Beispiel. Hier legen wir das Repository "REPOSITORY" an:

1
sudo su -m subversion -c "svnadmin create --config-dir=~/.subversion/servers /subversion/REPOSITORY"

In diesem neuen Repository befindet sich dann ein Unterordner namens "./conf", über den die Zugriffsrechte geregelt werden können. Dabei handelt es sich um die typische Subversion-Konfiguration bestehend aus der Datei "svnserve.conf" und der Datei "passwd".

Nun kann man, wenn man per SSH auf dem Server eingeloggt ist, bereits normal mit Subversion arbeiten - zum Beispiel, um neue Verzeichnisse anzulegen. Das funktioniert bereits alles über das SVN-Protokoll:

1
2
3
4
svn mkdir svn://SVNUSER@localhost/REPOSITORY/testprojekt -m "Testprojekt anlegen"
svn mkdir svn://SVNUSER@localhost/REPOSITORY/testprojekt/trunk -m "./trunk anlegen"
svn mkdir svn://SVNUSER@localhost/REPOSITORY/testprojekt/branches -m "./branches anlegen"
svn mkdir svn://SVNUSER@localhost/REPOSITORY/testprojekt/tags -m "./tags anlegen"

Für eine ordentliche Remotearbeit ist das jedoch nicht so das Gelbe vom Ei. Wir wollen ja auf unserem Rechner zum Beispiel TortoiseSVN verwenden können. Dank SSH-Portforwarding ist das jedoch kein wirkliches Problem. Statt uns mit einer interaktiven SSH-Shell mit dem Server zu verbinden, auf dem unser Subversion werkelt, können wir auch eine reine Portforwarding-Session öffnen. Das sähe dann so aus:

1
ssh SSHUSER@SSHSERVER -N -L 3690:localhost:3690

Wir machen hier nichts weiter, als eine SSH-Session zu öffnen und den SSH-Client anzuweisen, Verbindungen, die wir lokal auf Port 3690 öffnen an den Server durchzureichen. Dieser öffnet dann ebenfalls eine Verbindung - in unserem Fall zur Adresse "localhost:3690". Der Parameter "-N" weist den Client an, keine interaktive Shell zu starten.

Wenn wir nun einen Client wie SVN-Client wie TortoiseSVN verwenden, müssen wir diesen nur noch anweisen, das Repository "svn://localhost/REPOSITORY" zu verwenden - und schon kann es losgehen! 😀

Wie immer sind Anregungen, Fragen, Kritik und Verbesserungen gern gesehen. Wie kümmert ihr euch um die Versionierung eurer Dateien? Arbeitet ihr einfach lokal per Git? Verwendet ihr Github? Habt ihr einen Subversion-Server aufgebaut? Ich bin gespannt. 🙂
Versionierte Grüße, Kenny

2 Kommentare » Schreibe einen Kommentar

  1. Man hätte auch gitolite nutzen können, was so ziemlich deinen Anforderungen entspricht (wenn man deinen ersten Absatz richtig versteht).

    Wobei ich nicht verstehe, warum du diesen localhorst-Foo machst, der eigentlich nur eine Verschleierung des Remote-Servers vor dir selbst ist. Wenn ich etwas remote pushe oder pulle, sollte das klar an den URIs erkennbar sein. Die Länge der URIs kann ja auch nicht das Kriterium sein, denn letztlich benutzt du ja eh einen Client, der dir viel Tipparbeit erspart.

    Und da du schon so fragst:

    Ich fahre gemischt. Github nutze ich für OpenSource-Projekte, denn Github ist halt mehr als nur ein simples Git-Repo-Hosting.

    Für die eher nicht der Allgemeinheit zugänglichen Projekte betreibe ich auf einem Server eine gitolite-Instanz.

    Subversion ist für mich gestorben, als ich intensiver mit dem WordPress-Plugin-Repository arbeiten musste. Die Geschwindigkeit ist unterirdisch, weil man eben für jede Aktion mit dem Server reden muss. Und dass ich mir die Revisionsgeschichte mit allen teilen muss, ist nebst der .svn-Ordner-Epidemie noch so eine Unart.

    Um es kurz zu machen: Ich mag nicht diesen zentralistischen Ansatz. Gerade für Kleinstprojekte ist Subversion overkill.

    • Der Localhost-Foo hat den Sinn, dass dem Server von außen nicht ansehbar sein soll, dass dort ein Subversion-Server läuft. Dieser horcht eben nur auf der IP-Adresse "127.0.0.1". So hat man vor allem bei im Internet gehosteten Servern den Vorteil, dass nur derjenige ihn (potentiell) angreifen kann, der auch Zugriff auf Localhost hat (via SSH).

      Auch Git bietet eben diese Form der Sicherheit, nur, dass es dann eben nicht weiter geht. Jemand, der Zugriff auf den SSH-Server hat und mit Git arbeitet, muss zwingend Zugriff auf die eigentlichen Dateien haben. Bei Subversion ist das nicht der Fall. Dort dient svnserve als zweite Schutzschicht.

      Und zur ".svn"-Epidemie. Soweit ich gelesen habe, gibt es inzwischen nur noch einen ".svn"-Ordner in der Wurzel eines ausgecheckten Verzeichnisses (habe ehrlich gesagt noch nicht geguckt).

Schreibe einen Kommentar

Um Ihnen beim weiteren Kommentieren auf dieser Webseite die erneute Eingabe Ihrer Daten zu ersparen, wird beim Absenden Ihres Kommentars ein Cookie an Ihren Browser gesendet und von diesem gespeichert. Mit dem Absenden eines Kommentars auf dieser Webseite stimmen Sie der Speicherung und Übertragung dieses Cookies explizit zu.

Pflichtfelder sind mit * markiert.