Das Programm svnserve ist ein
leichtgewichtiger Server, welcher für die Kommunikation mit den
Clients ein auf TCP/IP basierendes, zustandsorientiertes
Protokoll verwendet. Um sich mit dem Server zu verbinden,
verwenden die Clients entweder das svn://
-
oder das svn+ssh://
-Schema. In diesem
Abschnitt behandeln wir die unterschiedlichen Möglichkeiten,
svnserve einzusetzen, wie sich die Clients am
Server authentisieren und wie die passenden Zugangsrechte zum
Projektarchiv korrekt eingerichtet werden.
Es gibt mehrere Möglichkeiten, svnserve zu starten:
svnserve als eigenständigen Dienst (engl. daemon) starten und auf Anfragen von Clients reagieren lassen.
svnserve bei Bedarf mit Hilfe des Unix-Dienstes inetd starten, wenn auf einem festgelegten Port Anfragen eines svn-Clients ankommen.
Einen SSH-Server verwenden, um svnserve fallweise über einen verschlüsselten SSH-Tunnel zu betreiben.
svnserve als Microsoft-Windows-Dienst laufen lassen.
Die einfachste Variante ist, svnserve
als eigenständigen (Unix-)Dienst laufen zu lassen. Verwenden
Sie hierfür die -d
Option beim Aufruf:
$ svnserve -d $ # svnserve läuft nun als Dienst und lauscht auf Port 3690
Wird svnserve als Dienst betrieben,
können Sie mit den Optionen --listen-port
und --listen-host
festlegen, auf welchem
Port und unter welchem Hostnamen er lauschen soll.
Wurde svnserve auf diese Weise
erfolgreich gestartet, stehen nun alle Projektarchive auf
dem Server für Nutzer im Netzwerk zur Verfügung. Für einen
Zugriff muss ein Client den absoluten
Pfad zum Projektarchiv im URL angeben. Ist das Projektarchiv
beispielsweise im Verzeichnis
/var/svn/project1
gespeichert, so sieht
ein entsprechender URL für den Zugriff folgendermaßen aus:
svn://host.example.com/var/svn/project1
. Um die
Sicherheit zu erhöhen, kann svnserve beim
Start mit der Option -r
auf ein bestimmtes
Verzeichnis beschränkt werden, so dass nur noch die darin
liegenden Projektarchive im Netz verfügbar sind. Ein
Beispiel:
$ svnserve -d -r /var/svn …
Mit der -r
-Option wird festgelegt,
welches Verzeichnis vom svnserve bei
Anfragen als Wurzelverzeichnis (engl. root) verwendet wird.
Ein Client muss nun in seiner URL nur noch den Pfad relativ
zum neuen Wurzelverzeichnis angeben, was die URL erheblich
verkürzt und die Verzeichnisstruktur etwas
verschleiert:
$ svn checkout svn://host.example.com/project1 …
Wenn Sie inetd zum Starten des
Prozesses verwenden wollen, so übergeben Sie
svnserve beim Aufruf die Option
-i
(--inetd
). Im folgenden
Beispiel sehen wir die Ausgaben beim Aufruf von
svnserve -i
auf der Kommandozeile. Beachten Sie aber, dass dies nicht
der Weg ist, wie der Dienst normalerweise gestartet wird
– eine genaue Beschreibung, wie
svnserve über inetd
gestartet wird, folgt anschließend.
$ svnserve -i ( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline ) ) )
Mit der --inetd
-Option versucht
svnserve mit dem Subversion-Client unter
Verwendung eines speziellen Protokolls via
stdin
und stdout
zu sprechen. Dies ist der normale Weg für ein Programm,
welches über inetd gestartet wurde. Die
IANA (Internet Assigned Numbers Authority) hat für das
Subversion-Protokoll den Port 3690 reserviert – auf
einem Unix-ähnlichen System fügen Sie einfach folgende
Zeilen (wenn noch nicht vorhanden) in die Datei
/usw/services
ein:
svn 3690/tcp # Subversion svn 3690/udp # Subversion
Wenn Sie den klassischen Unix-inetd
verwenden, können Sie die folgende Zeile in die Datei
/usw/inetd.conf
einfügen:
svn stream tcp nowait svnowner /usr/bin/svnserve svnserve -i
Stellen Sie sicher, dass „svnowner“ der
Nutzer ist, welcher alle notwendigen Zugriffsrechte auf ihre
Projektarchive hat. Kommt nun eine Anfrage eines
Subversion-Clients auf Port 3690 herein, so wird
inetd einen
svnserve-Prozess starten, um die Anfrage
zu bedienen. Wahrscheinlich möchten Sie noch die
-r
-Option zur oben genannten Zeile
hinzufügen, um einzuschränken, welche Projektarchive
exportiert werden dürfen.
Eine dritte Möglichkeit ist, svnserve
mittels der -t
-Option im Tunnel-Modus
aufzurufen. Bei diesem Aufruf wird vorausgesetzt, dass ein
anderes Programm für den Remote-Zugriff – etwa
rsh oder ssh –
den Nutzer bereits erfolgreich authentisiert hat, um nun
einen privaten
svnserve-Prozess als dieser
Nutzer zu starten. (Beachten Sie, dass für Sie
als Nutzer selten bis nie die Notwendigkeit bestehen wird,
svnserve mit der
-t
-Option von Hand auf der Kommandozeile
aufzurufen – der SSH-Dienst wird dies in der Regel für
Sie machen.) svnserve wird sich nun
normal verhalten (Abwicklung der Kommunikation über
stdin
und stdout
)
und davon ausgehen, dass alle Daten mit Hilfe des Tunnels
zum Client weitergeleitet werden. Wird
svnserve wie in diesem Fall durch ein
Tunnel-Programm aufgerufen, ist es notwendig, dass der
aufrufende Nutzer volle Lese- und Schreibrechte auf die
Dateien der Projektarchiv-Datenbank hat. Es verhält sich
dabei im Grunde genommen so, als wenn der Nutzer mit einem
file://
-URL auf ein Projektarchiv
zugreifen würde.
Wir werden diese Option noch genauer in diesem Kapitel behandeln, und zwar in „Tunneln über SSH“.
Gehört ihr Windows zur NT-Familie (2000, 2003, XP oder
Vista), so können Sie svnserve auch als
normalen Windows-Dienst laufen lassen. Dies ist wesentlich
sinnvoller, als die Option --daemon
(-d
) zu verwenden und ihn als
selbstständigen Dienst zu betreiben. Sie müssten dann immer
eine Konsole (cmd) öffnen, den passenden Befehl aufrufen und
die Konsole anschließend die ganze Zeit geöffnet lassen. Ein
Windows-Dienst dagegen läuft im Hintergrund, kann bereits
beim Hochfahren automatisch starten und lässt sich wie jeder
andere Windows-Dienst mit demselben Administrationsprogramm
starten und stoppen.
Es ist notwendig, den neuen Windows-Dienst unter Verwendung des Kommandozeilenprogramms SC.EXE einzurichten. Ähnlich der inetd-Konfigurationszeile müssen Sie den genauen Aufruf für den Start von svnserve festlegen:
C:\> sc create svn binpath= "C:\svn\bin\svnserve.exe --service -r C:\repos" displayname= "Subversion Server" depend= Tcpip start= auto
Hiermit erzeugen Sie einen neuen Windows-Dienst mit dem
Namen „svn“, welcher jedes Mal das Programm
svnserve.exe startet (und in diesem Fall
C:\repos
als Wurzelverzeichnis
verwendet). In diesem Beispiel müssen jedoch einige
wichtige Punkte beachtet werden.
Als erstes ist es wichtig, dass das Programm
svnserve.exe immer mit der Option
--service
aufgerufen wird. Alle weiteren
Optionen müssen in derselben Zeile folgen, allerdings dürfen
sich widersprechende Option nicht verwendet werden –
wie etwa --daemon
(-d
),
--tunnel
oder --inetd
(-i
). Optionen wie -r
oder --listen-port
sind hingegen in
Ordnung. Zweitens, seien Sie beim Aufruf von
SC.EXE mit Leerzeichen vorsichtig: Beim
Schreiben der Schlüssel= Wert
-Zeile darf
zwischen Schlüssel
und
=
kein Leerzeichen stehen, vor
Wert
muss genau ein Leerzeichen stehen.
Seien Sie zuletzt auch bei der Verwendung von Leerzeichen
innerhalb ihres Kommandozeilenaufrufes vorsichtig. Sollten
Verzeichnisangaben etwa Leerzeichen (oder andere zu
schützende Zeichen) enthalten, so umschließen Sie sie mit
zusätzlichen doppelten Anführungszeichen:
C:\> sc create svn binpath= "\"C:\program files\svn\bin\svnserve.exe\" --service -r C:\repos" displayname= "Subversion Server" depend= Tcpip start= auto
Beachten Sie bitte auch, dass das Wort
binpath
etwas irreführend ist –
sein Wert ist eine Kommandozeile und
nicht der Pfad zu einem Programm. Dies ist der Grund, warum
Sie vorhandene Leerzeichen mit doppelten Anführungszeichen
schützen müssen.
Ist der Dienst erst einmal eingerichtet, können Sie ihn mit Hilfe von grafischen Programmen (etwa der Microsoft Management Console) stoppen, starten oder seinen Status abfragen. Alternativ steht ihnen auch die Kommandozeile zur Verfügung:
C:\> net stop svn C:\> net start svn
Der Dienst kann natürlich auch wieder deinstalliert
werden, indem Sie den Befehl sc delete
svn
aufrufen. Stoppen Sie den Dienst aber
vorher! Das Programm SC.EXE kennt noch
etliche andere nützliche Optionen und Parameter, ein Aufruf
von sc /?
verrät
ihnen, welche das sind.
Wenn sich ein Subversion-Client mit einem svnserve-Prozess verbindet, geschieht folgendes:
Der Client wählt ein bestimmtes Projektarchiv.
Der Server liest die zum Projektarchiv
gehörende Datei conf/svnserve.conf
und führt die darin enthaltenen Regeln für die
Authentifizierung (Legitimation, Identitätsprüfung) und
die Autorisierung (Berechtigungen, Befugnisse)
aus.
Je nach festgelegten Regeln und Einstellungen geht es mit einem der folgenden Punkte weiter:
Der Client kann seine Anfragen anonym, also ohne eine vorhergehende Authentifikationsanfrage, senden.
Der Client kann jederzeit eine Anmeldeaufforderung erhalten.
Läuft die Verbindung über einen Tunnel, so erklärt der Client, dass eine externe Anmeldung stattgefunden hat (meistens durch SSH).
Der svnserve-Server beherrscht als Standardeinstellung nur den CRAM-MD5-Anmeldedialog [39]. Im Kern läuft dieser wie folgt ab: Der Server sendet einen kleinen Datensatz als Anfrage an den Client. Dieser erzeugt mittels des MD5-Hash-Algorithmus einen Fingerabdruck/Hash des Passwortes zusammen mit dem Datensatz und sendet diesen Fingerabdruck als Antwort zurück an den Server. Der Server vollzieht nun dieselbe Operation mit dem Passwort und dem Datensatz und vergleicht anschließend seinen Fingerabdruck mit dem des Clients. Während des gesamten Vorgangs wird das eigentliche Passwort nie über das Netzwerk gesendet.
Enthält ihr svnserve-Server Unterstützung für SASL, so beherrscht er nicht nur die CRAM-MD5-Anmeldung, sondern noch eine Menge anderer Verfahren zur Authentifizierung. Lesen Sie „svnserve mit SASL verwenden“ weiter unten, um zu lernen, wie die einzelnen Möglichkeiten zur Authentifizierung und Verschlüsselung in SASL eingerichtet werden.
Es ist selbstverständlich auch möglich, dass sich der Client über ein eigenständiges Tunnel-Programm anmeldet, etwa ssh. In einem solchem Fall stellt der Server nur fest, unter welchem Anwenderkonto er gestartet wurde, und verwendet dieses für die weitere Anmeldung. Mehr dazu im Kapitel „Tunneln über SSH“.
Wie Sie sicher bereits bemerkt haben, ist die Datei
svnserve.conf
in jedem Projektarchiv die
zentrale Anlaufstelle für alle Regeln im Rahmen der
Anwenderanmeldung und Rechtevergabe. Die Datei hat dasselbe
Format wie die anderen Konfigurationsdateien (siehe „Laufzeit-Konfigurationsbereich“):
Die Abschnittsbezeichnungen sind von eckigen Klammern
umschlossen ([
und ]
),
Kommentare werden mit Rauten (#
)
eingeleitet, und jeder Abschnitt enthält spezielle Variablen,
denen Werte zugewiesen werden (variable =
value
). Lassen Sie uns einen Blick in diese
Dateien werfen, um zu sehen wie sie verwendet werden.
Zu Beginn enthält der Abschnitt
[general]
in der Datei
svnserve.conf
alle Einstellungen,
welche für den Start notwendig sind. Lassen Sie uns anfangen
und den Variablen Werte zuweisen: Wählen Sie den Namen der
Datei, welche die Namen ihrer Nutzer und deren Passwörter
enthält, und entscheiden Sie sich für den Namen der
Authentifikationsumgebung:
[general] password-db = passwortdatei realm = Anmeldedomäne
Den Namen des realm
können Sie frei
wählen. Er teilt den Clients mit, an welcher
„Authentifikationsumgebung“ sie sich anmelden.
Der Subversion-Client zeigt diesen Namen im Anmeldedialog
und verwendet ihn auch (zusammen mit dem Namen und Port des
Servers)
als Schlüssel, welcher als Teil des Anmeldenachweises auf
der Festplatte des Nutzers gespeichert wird (siehe dazu
„Zwischenspeicherung der Client-Zugangsdaten“). Die
Variable password-db
enthält den Namen
der Passwortdatei, die vom Aufbau her gleich ist und die
Namen der Nutzer und deren Passwörter speichert. Als
Beispiel:
[users] harry = geheimespasswort sally = undnocheins
Der Wert von password-db
kann den
absoluten oder relativen Pfad zur Anwenderdatei enthalten.
In der Regel, ist es am einfachsten diese Datei ebenfalls
im conf/
-Verzeichnis des
Projektarchivs zu speichern – also dort, wo auch
svnserve.conf
liegt. Andererseits
möchten Sie vielleicht eine Passwortdatei für mehrere
Projektarchive verwenden; in diesem Fall sollten Sie die
Datei an einem zentraleren Ort ablegen. Die
Projektarchive, die sich die Anwenderdatei teilen, sollten
so konfiguriert sein, dass sie derselben
Authentifikationsumgebung angehören, da die Anwenderliste
im Wesentlichen einen Authentifikations-Bereich definiert.
Wo die Datei auch liegen mag, stellen Sie sicher, die Lese-
und Schreibrechte entsprechend zu setzen. Falls Sie wissen,
unter welchem Konto svnserve laufen
wird, sollten Sie den Lesezugriff zur Anwenderdatei auf das
Notwendige beschränken.
Es sind noch zwei weitere Variablen in der Datei
svnserve.conf
zu setzten: Sie legen
fest, was nicht authentifizierten (anonymen) und
authentifizierten Nutzern erlaubt ist. Die Variablen
anon-access
und
auth-access
können auf die Werte
none
, read
oder
write
gesetzt werden. Wenn Sie den Wert
auf none
setzen, so unterbinden Sie
sowohl den Lese- als auch den Schreibzugriff –
read
erlaubt den Nur-Lese-Zugriff auf das
Projektarchiv und write
gibt auf das
gesamte Projektarchiv Lese- und Schreibzugriff.
[general] password-db = Anwenderdatei realm = Ihr realm # Anonyme Anwender können nur lesend zugreifen anon-access = read # Authentifizierte Anwender können sowohl lesen als auch schreiben auth-access = write
Tatsächlich sind die in diesem Beispiel gezeigten Einstellungen, auch die Standardwerte der Variablen, falls Sie vergessen sollten, sie zu setzten. Für den Fall, dass Sie noch zurückhaltender sein möchten, können Sie den anonymen Zugriff auch komplett unterbinden:
[general] password-db = Anwenderdatei realm = Ihr realm # Anonyme Anwender sind nicht erlaubt anon-access = none # Authentifizierte Anwender können sowohl lesen als auch schreiben auth-access = write
Der Serverprozess versteht nicht nur diese
„pauschalen“ Zugriffseinstellungen für ein
Projektarchiv, sondern auch feiner granulierte
Zugriffsrechte auf einzelne Dateien und Verzeichnisse
innerhalb des Projektarchive. Um diese Funktion nutzen zu
können, müssen Sie eine Datei anlegen, welche die
umfangreicheren Regeln enthält und anschließend die Variable
authz-db
mit folgenden Wert setzten:
[general] password-db = Anwenderdatei realm = Ihr realm # Zum Festlegen von umfangreicheren Zugriffsregeln für bestimmte Bereiche authz-db = Auth-Datei
Wir werden die Syntax der
Auth-Datei
noch später in diesem
Kapitel besprechen, und zwar in „Pfadbasierte Autorisierung“. Beachten Sie,
dass die authz-db
-Variable die Verwendung
der anon-access
- und
auth-access
-Variablen nicht ausschließt
– wenn alle diese Variablen gleichzeitig gesetzt sind,
so müssen auch alle diese Regeln
erfolgreich greifen, bevor ein Zugriff erlaubt wird.
Die meisten Teams benötigen lediglich die eingebaute CRAM-MD5 Authentifizierung von svnserve. Falls Ihr Server (und Ihre Subversion Clients) jedoch mit der Cyrus Simple Authentication and Security Layer (SASL) Bibliothek gebaut wurde, stehen Ihnen eine Reihe von Authentifikations- und Verschlüsselungsoptionen zur Verfügung.
Wenn ein Subversion-Client sich mit svnserve verbindet, sendet der Server normalerweise eine Begrüßung, die eine Auflistung der von ihm unterstützten Fähigkeiten umfasst, woraufhin der Client mit einer ähnlichen Liste von Fähigkeiten antwortet. Falls der Server so konfiguriert wurde, dass er eine Authentifikation benötigt, sendet er eine Aufforderung, die die verfügbaren Authentifikationsmechanismen auflistet; der Client antwortet, indem er einen der Mechanismen auswählt und die Authentifizierung erfolgt dann mittels eines Nachrichtenaustausches. Selbst falls keine SASL-Fähigkeiten vorhanden sind, verstehen Client und Server von sich aus die CRAM-MD5- und ANONYMOUS-Mechanismen (siehe „Integrierte Authentifizierung und Autorisierung“). Falls Client und Server mit SASL gebaut wurden, könnten eine Anzahl weiterer Authentifikationsmechanismen verfügbar sein. Trotzdem müssen Sie serverseitig ausdrücklich SASL konfigurieren, um es anbieten zu können.
Um bestimmte SASL-Mechanismen auf dem Server zu
aktivieren, müssen Sie zwei Dinge tun. Erstellen Sie
zunächst einen Abschnitt [sasl]
in der
Datei svnserve.conf
Ihres
Projektarchivs mit einem Schlüssel-Wert-Paar:
[sasl] use-sasl = true
Erstellen Sie zweitens eine
SASL-Hauptkonfigurationsdatei namens
svn.conf
dort, wo die SASL-Bibliothek
sie finden kann – typischerweise in dem Verzeichnis,
wo Sie müssen das Plug-in-Verzeichnis auf Ihrem System
lokalisieren, etwa /usr/lib/sasl2/
oder
/etc/sasl2/
. (Beachten Sie, dass es
sich hierbei nicht um die Datei
svnserve.conf
handelt, die innerhalb
eines Projektarchivs liegt!)
Auf einem Windows-Server müssen Sie außerdem die
Systemregistratur anpassen (mit einem Werkzeug wie
regedit), um SASL mitzuteilen, wo es
Dinge finden kann. Erstellen Sie einen Registraturschlüssel
namens [HKEY_LOCAL_MACHINE\SOFTWARE\Carnegie
Mellon\Project Cyrus\SASL Library]
und legen zwei
weitere Schlüssel hinein: einen Schlüssel namens
SearchPath
(dessen Wert ein Pfad zum
Verzeichnis bezeichnet, in dem die SASL
sasl*.dll
-Plug-in-Bibliotheken liegen)
und einen Schlüssel namens ConfFile
(dessen Wert ein Pfad zum Elternverzeichnis der von Ihnen
erstellten Datei svn.conf
ist).
Da SASL so viele unterschiedliche Arten von
Authentifikationsmechanismen zur Verfügung stellt, wäre es
töricht (und würde den Rahmen dieses Buches sprengen), wenn
wir versuchen würden, jede mögliche Server-Konfiguration zu
erläutern. Stattdessen empfehlen wir Ihnen, die Lektüre der
Dokumentation aus dem Unterverzeichnis
doc/
des SASL Quelltextes. Sie
beschreibt detailliert jeden Mechanismus und die
entsprechende Konfiguration des Servers. Für die Erörterung
an dieser Stelle zeigen wir ein einfaches Beispiel der
Konfiguration des DIGEST-MD5 Mechanismus. Wenn Ihre Datei
subversion.conf
(oder
svn.conf
) beispielsweise folgenden
Inhalt hat:
pwcheck_method: auxprop auxprop_plugin: sasldb sasldb_path: /etc/my_sasldb mech_list: DIGEST-MD5
haben Sie SASL aufgefordert, Clients den DIGEST-MD5
Mechanismus anzubieten und Anwenderpasswörter mit einer
privaten Passwort-Datenbank in
/etc/my_sasldb
abzugleichen. Ein
Systemadministrator kann dann mit dem Programm
saslpasswd2 Anwendernamen und Passwörter
in der Datenbank eintragen oder bearbeiten:
$ saslpasswd2 -c -f /etc/my_sasldb -u realm username
Ein paar Worte zur Warnung: Stellen Sie zunächst sicher
dass das Argument „realm“ für
saslpasswd2 demselben Bereich entspricht,
den Sie in der Datei svnserve.conf
Ihres Projektarchivs definiert haben; falls diese Werte nicht
übereinstimmen, wird die Authentifizierung fehlschlagen.
Darüber hinaus muss aufgrund einer Unzulänglichkeit in SASL
der gemeinsame Bereich aus einer Zeichenkette ohne
Leerzeichen bestehen. Falls Sie sich entscheiden, die
standardmäßige SASL-Passwort-Datenbank zu verwenden, sollten
Sie schließlich sicherstellen, dass das Programm
svnserve die Datei lesen (und
möglicherweise auch schreiben) kann, wenn Sie einen
Mechanismus wie OTP verwenden).
Dies ist lediglich eine einfache Art, SASL zu konfigurieren. Viele andere Authentifikationsmechanismen stehen zur Verfügung, und Passwörter können an anderer Stelle gespeichert werden, etwa in LDAP oder in einer SQL-Datenbank. Details hierzu finden Sie in der Dokumentation zu SASL.
Wenn Sie Ihren Server so konfigurieren, dass er nur bestimmte SASL-Authentifikationsmechanismen erlaubt, müssen Sie beachten, dass damit auch alle Clients gezwungen sind, SASL zu unterstützen. Kein Subversion-Client ohne SASL-Unterstützung (u.a. alle Clients vor Version 1.5) kann sich authentisieren. Andererseits möchten Sie vielleicht gerade diese Einschränkung („Meine Clients müssen sämtlich Kerberos verwenden!“). Wenn Sie jedoch möchten, dass sich auch Nicht-SASL-Clients authentisieren können, stellen Sie sicher, dass optional der CRAM-MD5-Mechanismus angeboten wird. Alle Clients können CRAM-MD5 verwenden, egal, ob sie SASL verstehen oder nicht.
SASL kann auch Daten verschlüsseln, sofern ein
bestimmter Mechanismus das unterstützt. Der eingebaute
CRAM-MD5-Mechanismus unterstützt keine Verschlüsselung,
jedoch DIGEST-MD5, und Mechanismen wie SRP erfordern sogar
die Verwendung der OpenSSL-Bibliothek. Um verschiedene
Verschlüsselungsstufen zu aktivieren oder abzustellen,
können Sie zwei Werte in der Datei
svnserve.conf
Ihres Projektarchivs
einstellen:
[sasl] use-sasl = true min-encryption = 128 max-encryption = 256
Die Variablen min-encryption
und
max-encryption
kontrollieren die vom
Server verlangte Verschlüsselungsstufe. Um Verschlüsselung
vollständig abzustellen, setzen Sie beide Werte auf 0. Um
die einfache Erstellung von Prüfsummen für Daten zu
ermöglichen (etwa, um Manipulationen zu verhindern und
Datenintegrität ohne Verschlüsselung zu garantieren), setzen
Sie beide Werte auf 1. Falls Sie Verschlüsselung erlauben,
jedoch nicht voraussetzen, setzen Sie den Minimalwert auf 0
und den Maximalwert auf irgendeine Bitlänge. Um unbedingte
Verschlüsselung zu verlangen,, setzen Sie beide Werte auf
Zahlen größer 1. Im vorangegangenen Beispiel verlangen wir,
dass Clients mindestens 128-Bit- aber höchstens
256-Bit-Verschlüsselung vornehmen.
Die eingebaute Authentifizierung (und die SASL-Unterstützung) von svnserve kann sehr praktisch sein, da es die Notwendigkeit echter Systemkonten vermeidet. Andererseits haben einige Administratoren bereits etablierte SSH-Authentifikations-Frameworks im Einsatz. In diesen Fällen haben die Anwender des Projektes bereits Systemkonten, um sich damit über SSH mit dem Server zu verbinden.
Es ist einfach, SSH in Verbindung mit
svnserve zu verwenden. Der Client benutzt
zum Verbinden einfach das svn+ssh://
URL-Schema:
$ whoami harry $ svn list svn+ssh://host.example.com/repos/project harryssh@host.example.com's password: ***** foo bar baz …
In diesem Beispiel ruft der Subversion-Client einen
lokalen ssh-Prozess auf, der sich mit
host.example.com
verbindet, sich (gemäß der
SSH-Anwenderkonfiguration) als Anwender
harryssh
authentisiert und dann auf dem
entfernten Rechner einen privaten
svnserve-Prozess unter der Anwenderkennung
harryssh
startet. Der Befehl
svnserve wird im Tunnelmodus
(-t
) aufgerufen und dessen Netzprotokoll wird
über die durch den Tunnelagenten ssh
verschlüsselte Verbindung „getunnelt“. Falls der
Client eine Übergabe macht, wird der authentifizierte
Anwendername harryssh
als Autor der neuen
Revision verwendet.
An dieser Stelle ist es wichtig, zu verstehen, dass der Subversion-Client sich nicht mit einem laufenden svnserve-Dämonen verbindet. Diese Zugriffsmethode benötigt keinen Dämonen und merkt auch nicht, wenn einer vorhanden ist. Sie verlässt sich vollständig auf die Fähigkeit von ssh, einen temporären svnserve-Prozesses zu starten, der nach dem Schließen der Netzverbindung beendet wird.
Denken Sie daran, dass beim Zugriff auf ein Projektarchiv
über URLs der Form svn+ssh://
die Abfrage
zur Authentifikation von ssh kommt und
nicht vom svn-Client.
Das bedeutet, dass es keine automatische Passwortspeicherung
gibt (siehe „Zwischenspeicherung der Client-Zugangsdaten“). Der
Subversion-Client stellt häufig mehrere Verbindungen mit dem
Projektarchiv her, wenngleich Anwender das wegen der
zwischengespeicherten Passwörter normalerweise gar nicht
mitbekommen. Jedoch könnten Anwender bei Verwendung von
svn+ssh://
-URLs durch die wiederholten
Passwortanfragen für ausgehende Verbindungen von
ssh etwas genervt sein. Die Lösung besteht
darin, ein zusätzliches Passwort-Speicherungs-Werkzeug wie
etwa ssh-agent auf einem Unix-ähnlichen
System oder pageant auf Windows zu
verwenden.
Bei der Verwendung eines Tunnels wird die Autorisierung
größtenteils durch die Betriebssystemberechtigungen auf die
Datenbankdateien des Projektarchivs gesteuert, als ob
Harry direkt über einen file://
-URL auf das
Projektarchiv zugreifen würde. Falls mehrere Anwender direkt
auf das Projektarchiv zugreifen sollen, möchten Sie sie
vielleicht in eine gemeinsame Gruppe zusammenfassen; Sie
sollten auch auf umasks achten (lesen Sie auf alle Fälle „Unterstützung mehrerer Zugriffsmethoden auf das Projektarchiv“ später in diesem
Kapitel). Doch selbst beim Tunneln können Sie immer noch die
Datei svnserve.conf
zum Blockieren des
Zugriffs verwenden, indem Sie einfach auth-access =
read
oder auth-access = none
setzen.
[40]
Vielleicht glauben Sie, dass die Geschichte mit dem
SSH-Tunneln hier endet. Es ist aber nicht so. Subversion
erlaubt es Ihnen, selbstdefinierte Verhaltensweisen für das
Tunneln in Ihrer Laufzeit-Datei config
zu definieren (siehe „Laufzeit-Konfigurationsbereich“).
Nehmen wir beispielsweise an, dass Sie RSH statt SSH verwenden
möchten.
[41]
Definieren Sie einfach im Abschnitt
[tunnels]
Ihrer Datei
config
:
[tunnels] rsh = rsh
Ab jetzt können Sie diese neue Tunneldefinition
verwenden, indem Sie ein URL-Schema benutzen, welches dem
Namen Ihrer neuen Variablen entspricht:
svn+rsh://host/path
. Bei Verwendung des
neuen URL-Schemas führt der Subversion-Client im Hintergrund
eigentlich den Befehl rsh host svnserve
-t
aus. Falls Sie einen Anwendernamen im URL
angeben (z.B.
svn+rsh://username@host/path
), wird der
Client das auch mit in seinen Befehl übernehmen
(rsh username@host svnserve -t
). Sie
können jedoch auch viel raffiniertere neue Tunnel-Schemata
definieren:
[tunnels] joessh = $JOESSH /opt/alternate/ssh -p 29934
Dieses Beispiel verdeutlicht einige Dinge. Erstens zeigt
es, wie der Subversion-Client angewiesen wird, ein bestimmtes
Tunnelprogramm (/opt/alternate/ssh
) mit
speziellen Optionen zu starten. In diesem Fall würde der
Zugriff auf einen URL wie svn+joessh://
das
bestimmte SSH-Programm mit den Argumenten -p
29934
aufrufen – was nützlich ist, wenn Sie
möchten, dass sich das Tunnelprogramm mit einem
Nicht-Standard-Port verbindet.
Zweitens zeigt es, wie eine eigene Umgebungsvariable
definiert werden kann, die den Namen des Tunnelprogramms
überschreibt. Durch das Setzen der Umgebungsvariablen
SVN_SSH
besteht eine bequeme Methode, den
Standard-SSH-Tunnelagenten zu ersetzen. Falls Sie jedoch für
unterschiedliche Server verschiedene Werte überschreiben
müssen, wobei jeder vielleicht einen anderen Port verwendet
oder unterschiedliche Optionen an SSH übergeben werden müssen,
können Sie die in diesem Beispiel vorgestellte Methode
verwenden. Falls wir nun die Umgebungsvariable
JOESSH
setzten, würde deren Wert den
gesamten Wert der Tunnelvariablen überschreiben – statt
/opt/alternate/ssh -p 29934
würde
$JOESSH ausgeführt.
Es ist möglich, nicht nur die Art und Weise zu steuern, auf die der Client ssh aufruft, sondern auch das Verhalten von sshd auf dem Server. In diesem Abschnitt zeigen wir, wie der von sshd ausgeführte svnserve-Befehl genau festgelegt wird sowie sich mehrere Anwender ein einzelnes Systemkonto teilen können.
Ermitteln Sie zunächst das Heimatverzeichnis des Kontos,
welches Sie zum Starten von svnserve
verwenden möchten. Stellen Sie sicher, dass für das Konto
ein Paar bestehend aus einem öffentlichen und einem privaten
SSH-Schlüssel installiert ist und dass sich der Anwender
über die Authentifikation mit einem öffentlichen Schlüssel
anmelden kann. Die Authentifikation mit Passwort wird nicht
funktionieren, da sich alle folgenden SSH-Tricks um die
Verwendung der SSH-Datei
authorized_keys
drehen.
Falls noch nicht geschehen, erzeugen Sie die Datei
authorized_keys
(unter Unix
üblicherweise ~/.ssh/authorized_keys
).
Jede Zeile dieser Datei beschreibt einen öffentlichen
Schlüssel, der sich verbinden darf. Die Zeilen sehen
normalerweise so aus:
ssh-dsa AAAABtce9euch… user@example.com
Das erste Feld beschreibt die Art des Schlüssels, das
zweite ist der eigentliche in Base64 codierte Schlüssel und
das dritte Feld ist ein Kommentar. Es ist jedoch weniger
bekannt, dass die gesamte Zeile mit einem
command
-Feld beginnen kann:
command="program" ssh-dsa AAAABtce9euch… user@example.com
Falls das Feld command
definiert ist,
wird der SSH-Daemon das angegebene Programm starten anstatt
wie üblich den vom Subversion-Client geforderten Aufruf von
svnserve im Tunnelmodus auszuführen. Das
öffnet die Tür für eine Reihe von serverseitigen Tricks. In
den folgenden Beispielen werden wir die Zeilen der Datei wie
folgt abkürzen:
command="program" TYPE KEY COMMENT
Da wir den durch den Server ausgeführten Befehl angeben können, ist es leicht, ein bestimmtes svnserve-Programm zu benennen und ihm zusätzliche Argumente mitzugeben:
command="/path/to/svnserve -t -r /virtual/root" TYPE KEY COMMENT
In diesem Beispiel könnte es sich bei
/path/to/svnserve
um ein
maßgeschneidertes Wrapper-Skript für
svnserve handeln, das die umask setzt
(siehe „Unterstützung mehrerer Zugriffsmethoden auf das Projektarchiv“). Es
wird außerdem veranschaulicht, wie
svnserve in einem virtuellen
Wurzelverzeichnis verankert wird, so wie es oft gemacht
wird, wenn svnserve als Daemon-Prozess
läuft. Das könnte entweder geschehen, um den Zugriff auf
Teile des Systems einzuschränken oder um dem Anwender die
Bürde abzunehmen, einen absoluten Pfad im URL
svn+ssh://
angeben zu müssen.
Es besteht weiterhin die Möglichkeit, dass sich mehrere
Anwender ein einzelnes Konto teilen. Statt ein gesondertes
Konto für jeden Anwender zu erstellen, generieren Sie für
jede Person jeweils ein Paar aus einem öffentlichen und
einem privaten Schlüssel. Tragen Sie dann jeden öffentlichen
Schlüssel in eine eigene Zeile der Datei
authorized_users
ein und verwenden die
Option --tunnel-user
:
command="svnserve -t --tunnel-user=harry" TYPE1 KEY1 harry@example.com command="svnserve -t --tunnel-user=sally" TYPE2 KEY2 sally@example.com
Dieses Beispiel erlaubt sowohl Harry als auch Sally,
sich über die Authentifikation durch einen öffentlichen
Schlüssel mit demselben Konto zu verbinden. Beide verfügen
über einen angepassten Befehl, der ausgeführt wird. Die
Option --tunnel-user
teilt
svnserve mit, das benannte Argument als
den authentifizierten Anwender zu akzeptieren. Ohne
--tunnel-user
sähe es so aus als kämen alle
Übergaben vom gemeinsamen Konto.
Ein letztes Wort zur Warnung: Die Zugangsberechtigung
für einen Anwender über einen öffentlichen Schlüssel und ein
gemeinsames Konto könnte noch weitere SSH-Zugänge erlauben,
selbst wenn Sie einen Wert für command
in
in authorized_keys
angegeben haben. So
kann der Anwender beispielsweise Shell-Zugang über SSH
erlangen oder X11 oder allgemeine Portweiterleitung über
Ihren Server einrichten. Um Ihrem Anwender die
geringstmögliche Erlaubnis zu erteilen, sollten Sie
unmittelbar nach command
eine Reihe
einschränkender Optionen angeben:
command="svnserve -t --tunnel-user=harry",no-port-forwarding,no-agent-forw arding,no-X11-forwarding,no-pty TYPE1 KEY1 harry@example.com
Beachten Sie, dass alles auf einer Zeile stehen muss
– tatsächlich auf einer Zeile – da die
SSH-Dateien authorized_keys
nicht
einmal das übliche Backslash-Zeichen (\
)
zur Zeilenfortsetzung erlauben. Der einzige Grund für den
von uns eingefügten Zeilenumbruch ist die Unterbringung auf
der Breite einer Buchseite.