[svnbook] r4597 committed - Translation: Authentication Options
svnbook at googlecode.com
svnbook at googlecode.com
Fri Dec 27 16:22:27 CST 2013
Revision: 4597
Author: jmfelderhoff at gmx.eu
Date: Fri Dec 27 19:31:50 2013 UTC
Log: Translation: Authentication Options
http://code.google.com/p/svnbook/source/detail?r=4597
Modified:
/branches/1.6/de/book/ch06-server-configuration.xml
=======================================
--- /branches/1.6/de/book/ch06-server-configuration.xml Fri Dec 27 18:48:49
2013 UTC
+++ /branches/1.6/de/book/ch06-server-configuration.xml Fri Dec 27 19:31:50
2013 UTC
@@ -3967,403 +3967,114 @@
<sect3 id="svn.serverconfig.httpd.authn.digest">
<title>Digest authentication</title>
<!--
- <para>Another option is to not use Basic authentication, but to
- use Digest authentication instead. Digest authentication
- allows the server to verify the client's
- identity <emphasis>without</emphasis> passing the plain-text
- password over the network. Assuming that the client and
- server both know the user's password, they can verify that
- the password is the same by using it to apply a hashing
- function to a one-time bit of information. The server sends
- a small random-ish string to the client; the client uses the
- user's password to hash the string; the server then looks to
- see whether the hashed value is what it expected.</para>
+ <para>Digest authentication is an improvement on Basic
+ authentication which allows the server to verify a client's
+ identity without sending the password over the network
+ unprotected. Both client and server create a non-reversible
+ MD5 hash of the username, password, requested URI, and a
+ <firstterm>nonce</firstterm> (number used once) provided by
+ the server and changed each time authentication is required.
+ The client sends its hash to the server, and the server then
+ verifies that the hashes match.</para>
-->
- <para>Eine weitere Option besteht darin, statt der
- Basic-Authentifizierung die Digest-Authentifizierung zu
- verwenden. Digest-Authentifizierung erlaubt es dem Server,
- die Identität des Clients zu bestätigen,
- <emphasis>ohne</emphasis> das Passwort als Klartext durch
- das Netz zu schicken. Unter der Voraussetzung, dass sowohl
- dem Client als auch dem Server das Passwort des Anwenders
- bekannt ist, können sie verifizieren, dass das Passwort
- dasselbe ist, indem sie eine Hashfunktion auf ein
- Einweg-Informationshäppchen anwenden. Der Server sendet eine
- kleine zufällige Zeichenkette an den Client. Der Client
- verwendet das Passwort des Anwenders, um die Zeichenkette zu
- hashen, und der Server prüft dann, ob der gehashte Wert dem
- erwarteten Ergebnis entspricht.</para>
+ <para>Digest-Authentifizierung ist eine Verbesserung der
+ Basic-Authentifizierung, die es dem Server ermöglicht,
+ die Identität des Clients zu bestätigen, ohne das Passwort
+ ungeschützt durch das Netz zu schicken. Sowohl Client als
+ auch Server erzeugen einen nicht rückgängig zu machenden
+ MD5-Hashwert des Anwendernamens, Passworts, verlangter URI
+ und einer Einwegnummer, die vom Server vergeben wird und
+ jedes Mal geändert wird, wenn eine Authentifizierung
+ benötigt wird. Der Client sendet seinen Hash an den Server
+ und der Server verifiziert dann, dass die Hashes
+ zusammenpassen.</para>
<!--
- <para>Configuring Apache for Digest authentication is also
- fairly easy, and only a small variation on our prior
- example. Be sure to consult Apache's documentation for full
- details.</para>
+ <para>Configuring Apache to use Digest authentication is
+ straightforward, with only small variations on our prior
+ example:</para>
-->
- <para>Es ist auch ziemlich einfach, Apache für die
- Digest-Authentifizierung zu konfigurieren und lediglich eine
- kleine Abweichung des vorangegangenen Beispiels. Für weitere
- Einzelheiten wird die Dokumentation zu Apache
- empfohlen.</para>
+ <para>Die Konfigurierung von Apache für die
+ Digest-Authentifizierung ist unkompliziert und nur eine
+ kleine Abweichung von unserem vorangegangenen
+ Beispiel:</para>
- <screen>
+ <informalexample>
+ <programlisting>
<Location /svn>
DAV svn
SVNParentPath /var/svn
- AuthType Digest
+
+ # Authentication: Digest
AuthName "Subversion repository"
- AuthDigestDomain /svn/
- AuthUserFile /etc/svn-auth-file
+ AuthType Digest
+ AuthUserFile /etc/svn-auth.htdigest
+
+ # Authorization: Authenticated users only
Require valid-user
</Location>
-</screen>
+</programlisting>
+ </informalexample>
<!--
- <para>If you're looking for maximum security, public key
- cryptography is the best solution. It may be best to use
- some sort of SSL encryption, so that clients authenticate
- via <literal>https://</literal> instead
- of <literal>http://</literal>; at a bare minimum, you can
- configure Apache to use a self-signed server certificate.
- <footnote>
- <para>While self-signed server certificates are still
- vulnerable to a <quote>man-in-the-middle</quote> attack,
- such an attack is much more difficult for a casual
- observer to pull off, compared to sniffing unprotected
- passwords.</para>
- </footnote>
- Consult Apache's documentation (and OpenSSL documentation)
- about how to do that.</para>
+ <para>Notice that <literal>AuthType</literal> is now set to
+ <literal>Digest</literal>, and we specify a different path
+ for <literal>AuthUserFile</literal>. Digest authentication
+ uses a different file format than Basic authentication; it
+ is created using Apache's <command>htdigest</command>
+ utility<footnote><para>See
+ <ulink
url="http://httpd.apache.org/docs/current/programs/htdigest.html"
+ />.</para></footnote> rather
+ than <command>htpasswd</command>. Digest authentication
+ also has the additional concept of a
+ <quote>realm</quote>, which must match the value of the
+ <literal>AuthName</literal> directive. The password file
+ can be created as follows:</para>
-->
- <para>Falls Sie maximale Sicherheit anstreben, ist ein
- asymmetrisches Kryptosystem das Mittel der Wahl. Am besten
- sollte eine Art der SSL-Verschlüsselung eingesetzt werden, so
- dass Clients sich über <literal>https://</literal> statt
- <literal>http://</literal> authentisieren; als
- Minimallösung können Sie Apache so einstellen, dass ein
- selbstsigniertes Server-Zertifikat verwendet wird.
- <footnote>
- <para>Obwohl selbstsignierte Server-Zertifikate immer noch
- verwundbar für einen
- <quote>Man-in-the-middle</quote>-Angriff sind, ist
- solch ein Angriff für einen gelegentlichen Beobachter
- ungleich schwieriger durchzuführen als ungeschützte
- Passwörter abzugreifen.</para>
- </footnote>
- Wie das bewerkstelligt wird, ist der Dokumentation von
- Apache (und OpenSSL) zu entnehmen.</para>
+ <para>Beachten Sie, dass <literal>AuthType</literal> nun auf
+ <literal>Digest</literal> gesetzt ist, und wir einen
+ unterschiedlichen Pfad für <literal>AuthUserFile</literal>
+ angegeben haben. Digest-Authentifizierung verwendet ein
+ unterschiedliches Dateiformat als Basic-Authentifizierung;
+ es wird mit Apaches Dienstprogramm
+ <command>htdigest</command> erzeugt<footnote><para>Siehe
+ <ulink
url="http://httpd.apache.org/docs/current/programs/htdigest.html"
+ />.</para></footnote> statt mit <command>htpasswd</command>.
+ Digest-Authentifizierung besitzt auch das zusätzliche
+ Konzept eines Bereichs, <quote>realm</quote>, der dem Wert
+ der Direktive <literal>AuthName</literal> entsprechen muss.
+ Die Passwortdatei kann wie folgt erzeugt werden:</para>
- </sect3>
-
-
- <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-->
- <sect3 id="svn.serverconfig.httpd.authn.sslcerts">
<!--
- <title>SSL certificate management</title>
--->
- <title>SSL-Zertifikatsverwaltung</title>
-
-<!--
- <para>Businesses that need to expose their repositories for access
- outside the company firewall should be conscious of the
- possibility that unauthorized parties could be
- <quote>sniffing</quote> their network traffic. SSL makes
- that kind of unwanted attention less likely to result in
- sensitive data leaks.</para>
--->
- <para>Unternehmen, die ihre Projektarchive für den Zugriff von
- außerhalb der Firewall freigeben müssen, sollten sich
- bewusst sein, dass Unbefugte den Netzverkehr
- <quote>abhören</quote> könnten. SSL lässt diese Art
- unerwünschte Aufmerksamkeit weniger anfällig für heikle
- Datenlecks werden.</para>
-
-<!--
- <para>If a Subversion client is compiled to use OpenSSL,
- it gains the ability to speak to an Apache server via
- <literal>https://</literal> URLs. The Neon library used by
- the Subversion client is not only able to verify server
- certificates, but can also supply client certificates when
- challenged. When the client and server have exchanged SSL
- certificates and successfully authenticated one another, all
- further communication is encrypted via a session key.</para>
--->
- <para>Ist ein Subversion-Client für die Verwendung von OpenSSL
- übersetzt worden, ist er in der Lage, mit einem
- Apache-Server über <literal>https://</literal>-URLs zu
- kommunizieren. Die vom Subversion-Client verwendete
- Neon-Bibliothek kann nicht nur Server-Zertifikate
- zertifizieren, sondern nach Aufforderung auch
- Client-Zertifikate liefern. Wenn der Client und der Server
- SSL-Zertifikate ausgetauscht und sich gegenseitig
- erfolgreich authentifiziert haben, wird jede weitere
- Kommunikation durch einen Sitzungsschlüssel
- verschlüsselt.</para>
-
-<!--
- <para>It's beyond the scope of this book to describe how to
- generate client and server certificates and how to
- configure Apache to use them. Many other books, including
- Apache's own documentation, describe this task. But what we
- <emphasis>can</emphasis> cover here is how to manage
- server and client certificates from an ordinary Subversion
- client.</para>
--->
- <para>Es würde den Rahmen dieses Buches sprengen, wenn
- beschrieben würde, wie Client- und Server-Zertifikate erzeugt
- werden und wie Apache für ihre Verwendung konfiguriert wird.
- Viele andere Bücher, darunter Apaches eigene Dokumentation,
- erläutern diese Aufgabe. Was wir an dieser Stelle jedoch
- behandeln <emphasis>können</emphasis>, ist die Verwaltung
- der Client- und Server-Zertifikate durch einen gewöhnlichen
- Subversion-Client.</para>
-
-<!--
- <para>When speaking to Apache via <literal>https://</literal>,
- a Subversion client can receive two different types of
- information:</para>
--->
- <para>Wenn über <literal>https://</literal> mit Apache
- gesprochen wird, kann ein Subversion-Client zwei
- unterschiedliche Arten von Informationen empfangen:</para>
-
-<!--
- <itemizedlist>
- <listitem><para>A server certificate</para></listitem>
- <listitem><para>A demand for a client
certificate</para></listitem>
- </itemizedlist>
--->
- <itemizedlist>
- <listitem><para>Ein Server-Zertifikat</para></listitem>
- <listitem><para>Eine Anfrage nach einem
- Client-Zertifikat</para></listitem>
- </itemizedlist>
-
-<!--
- <para>If the client receives a server certificate, it needs to
- verify that it trusts the certificate: is the server really
- who it claims to be? The OpenSSL library does this by
- examining the signer of the server certificate, or
- <firstterm>certificate authority</firstterm> (CA). If
- OpenSSL is unable to automatically trust the CA, or if some
- other problem occurs (such as an expired certificate or
- hostname mismatch), the Subversion command-line client will
- ask you whether you want to trust the server certificate
- anyway:</para>
--->
- <para>Wenn der Client ein Server-Zertifikat empfängt, muss er
- sicherstellen, dass er dem Zertifikat vertrauen kann:
- handelt es sich bei dem Server wirklich um denjenigen, für
- den er sich ausgibt? Die OpenSSL-Bibliothek macht das, indem
- der Unterzeichner des Server-Zertifikats, die sogenannte
- <firstterm>Certificate Authority</firstterm> (CA), oder
- Zertifizierungsstelle, untersucht wird. Falls OpenSSL der CA
- nicht automatisch vertrauen kann, oder falls ein anderes
- Problem auftaucht (etwa ein abgelaufenes Zertifikat oder ein
- nicht übereinstimmender Rechnername), fragt Sie der
- Subversion-Kommandozeilenclient, ob Sie dem
- Server-Zertifikat dennoch vertrauen möchten:</para>
-
-<!--
- <screen>
-$ svn list https://host.example.com/repos/project
-
-Error validating server certificate for 'https://host.example.com:443':
- - The certificate is not issued by a trusted authority. Use the
- fingerprint to validate the certificate manually!
-Certificate information:
- - Hostname: host.example.com
- - Valid: from Jan 30 19:23:56 2004 GMT until Jan 30 19:23:56 2006 GMT
- - Issuer: CA, example.com, Sometown, California, US
- - Fingerprint: 7d:e1:a9:34:33:39:ba:6a:e9:a5:c4:22:98:7b:76:5c:92:a0:9c:7b
-
-(R)eject, accept (t)emporarily or accept (p)ermanently?
+ <informalexample>
+ <screen>
+$ ### First time: use -c to create the file
+$ htdigest -c /etc/svn-auth.htdigest "Subversion repository" harry
+Adding password for harry in realm Subversion repository.
+New password: *****
+Re-type new password: *****
+$ htdigest /etc/svn-auth.htdigest "Subversion repository" sally
+Adding user sally in realm Subversion repository
+New password: *******
+Re-type new password: *******
+$
</screen>
--->
- <screen>
-$ svn list https://host.example.com/repos/project
-
-Fehler bei der Validierung des Serverzertifikats für
»https://host.example.com:443«:
- - Das Zertifikat ist nicht von einer vertrauenswürdigen Instanz
ausgestellt
- Überprüfen Sie den Fingerabdruck, um das Zertifikat zu validieren!
-Zertifikats-Informationen:
- - Hostname: host.example.com
- - Gültig: von Jan 30 19:23:56 2004 GMT bis Jan 30 19:23:56 2006 GMT
- - Aussteller: CA, example.com, Sometown, California, US
- - Fingerabdruck:
7d:e1:a9:34:33:39:ba:6a:e9:a5:c4:22:98:7b:76:5c:92:a0:9c:7b
-
-Ve(r)werfen, (t)emporär akzeptieren oder (p)ermanent akzeptieren?
-</screen>
-
-<!--
- <para>This dialogue should look familiar; it's essentially the
- same question you've probably seen coming from your web
- browser (which is just another HTTP client like Subversion).
- If you choose the <literal>(p)</literal>ermanent option, the
server certificate
- will be cached in your private runtime
- <filename>auth/</filename> area in just the same way your
- username and password are cached (see <xref
- linkend="svn.serverconfig.netmodel.creds"/>). If cached,
- Subversion will automatically trust this certificate
- in future negotiations.</para>
--->
- <para>Dieser Dialog sollte Ihnen bekannt vorkommen; im
- Wesentlichen ist es dieselbe Frage, die Sie wahrscheinlich
- bei Ihrem Web-Browser gesehen haben (der auch bloß ein
- weiterer HTTP-Client ist, so wie Subversion). Falls Sie die
- Option <literal>(p)</literal>ermanent
- auswählen, wird das Server-Zertifikat in Ihrem privaten
- Laufzeit-<filename>auth/</filename>-Bereich
- zwischengespeichert, ebenso wie Ihr Anwendername und
- Passwort (siehe <xref
- linkend="svn.serverconfig.netmodel.creds"/>). Falls es
- zwischengespeichert ist, wird Subversion diesem Zertifikat
- bei künftigen Protokollverhandlungen vertrauen.</para>
-
-<!--
- <para>Your runtime <filename>servers</filename> file also gives
- you the ability to make your Subversion client automatically
- trust specific CAs, either globally or on a per-host basis.
- Simply set the <literal>ssl-authority-files</literal>
- variable to a semicolon-separated list of PEM-encoded CA
- certificates:</para>
--->
- <para>Ihre Laufzeit-Datei <filename>servers</filename>
- ermöglicht es Ihrem Client auch, automatisch bestimmten CAs
- zu vertrauen, entweder global oder pro Host. Setzen Sie die
- Variable <literal>ssl-authority-files</literal> auf eine
- durch Semikolons getrennte Liste PEM-kodierter
- CA-Zertifikate:</para>
-
- <screen>
-[global]
-ssl-authority-files = /path/to/CAcert1.pem;/path/to/CAcert2.pem
-</screen>
-
-<!--
- <para>Many OpenSSL installations also have a predefined set
- of <quote>default</quote> CAs that are nearly universally
- trusted. To make the Subversion client automatically trust
- these standard authorities, set the
- <literal>ssl-trust-default-ca</literal> variable to
- <literal>true</literal>.</para>
--->
- <para>Viele OpenSSL-Installationen besitzen auch eine
- vordefinierte Menge von <quote>Standard</quote>-CAs, denen
- nahezu allgemein vertraut wird. Damit der Subversion-Client
- diesen Standard-Zertifizierungsstellen automatisch vertraut,
- setzen Sie die Variable
- <literal>ssl-trust-default-ca</literal> auf
- <literal>true</literal>.</para>
-
-<!--
- <para>When talking to Apache, a Subversion client might also
- receive a challenge for a client certificate. Apache is
- asking the client to identify itself: is the client really
- who it says it is? If all goes correctly, the Subversion
- client sends back a private certificate signed by a CA that
- Apache trusts. A client certificate is usually stored on
- disk in encrypted format, protected by a local password.
- When Subversion receives this challenge, it will ask you for
- a path to the certificate and the password that
- protects it:</para>
+ </informalexample>
-->
- <para>Bei der Kommunikation mit Apache kann ein
- Subversion-Client die Aufforderung erhalten, ein
- Client-Zertifikat vorzulegen. Apache ersucht den Client,
- sich zu identifizieren; ist der Client wirklich derjenige,
- als der er sich ausgibt? Wenn alles richtig funktioniert,
- schickt der Client ein privates Zertifikat zurück, das von
- einer CA signiert wurde, der Apache vertraut. Für gewöhnlich
- wird ein Client-Zertifikat, durch ein lokales Passwort
- geschützt, verschlüsselt auf Platte gespeichert. Wenn
- Subversion diese Aufforderung erhält, fragt es Sie nach dem
- Pfad zum Zertifikat und dem Passwort:</para>
-
-<!--
- <screen>
-$ svn list https://host.example.com/repos/project
-
-Authentication realm: https://host.example.com:443
-Client certificate filename: /path/to/my/cert.p12
-Passphrase for '/path/to/my/cert.p12': ********
-…
+ <informalexample>
+ <screen>
+$ ### Beim ersten Mal: -c zum Erzeugen der Datei verwenden
+$ htdigest -c /etc/svn-auth.htdigest "Subversion repository" harry
+Adding password for harry in realm Subversion repository.
+New password: *****
+Re-type new password: *****
+$ htdigest /etc/svn-auth.htdigest "Subversion repository" sally
+Adding user sally in realm Subversion repository
+New password: *******
+Re-type new password: *******
+$
</screen>
--->
- <screen>
-$ svn list https://host.example.com/repos/project
-
-Anmeldebereich: https://host.example.com:443
-Client Zertifikatsdatei: /path/to/my/cert.p12
-Passphrase für »/path/to/my/cert.p12«: ********
-…
-</screen>
-
-<!--
- <para>Notice that the client certificate is a
- <quote>p12</quote> file. To use a client certificate with
- Subversion, it must be in PKCS#12 format, which is a
- portable standard. Most web browsers are already able to
- import and export certificates in that format. Another
- option is to use the OpenSSL command-line tools to convert
- existing certificates into PKCS#12.</para>
--->
- <para>Beachten Sie, dass das Client-Zertifikat eine
- <quote>p12</quote>-Datei ist. Um ein Client-Zertifikat mit
- Subversion verwenden zu können, muss es im PKCS#12-Format
- sein, was einem portablen Standard entspricht. Die meisten
- Web-Browser können bereits Zertifikate in diesem Format im-
- und exportieren. Eine weitere Option ist es, die
- OpenSSL-Kommandozeilenwerkzeuge zu verwenden, um bestehende
- Zertifikate in PKCS#12 zu überführen.</para>
-
-<!--
- <para>Again, the runtime <filename>servers</filename> file
- allows you to automate this challenge on a per-host basis.
- Either or both pieces of information can be described in
- runtime variables:</para>
--->
- <para>Auch hier erlaubt Ihnen die Laufzeitdatei
- <filename>servers</filename>, diese Aufforderung pro Host zu
- automatisieren. Diese Informationen lassen sich für sich
- oder gemeinsam in Laufzeitvariablen beschreiben:</para>
-
- <screen>
-[groups]
-examplehost = host.example.com
-
-[examplehost]
-ssl-client-cert-file = /path/to/my/cert.p12
-ssl-client-cert-password = somepassword
-</screen>
-
-<!--
- <para>Once you've set the
- <literal>ssl-client-cert-file</literal> and
- <literal>ssl-client-cert-password</literal> variables, the
- Subversion client can automatically respond to a client
- certificate challenge without prompting you.
- <footnote>
- <para>More security-conscious folk might not want to store
- the client certificate password in the runtime
- <filename>servers</filename> file.</para>
- </footnote>
- </para>
--->
- <para>Sobald die Variablen
- <literal>ssl-client-cert-file</literal> und
- <literal>ssl-client-cert-password</literal> gesetzt sind,
- kann der Subversion-Client automatisch auf eine Anforderung
- eines Client-Zertifikats antworten, ohne eine Eingabe von
- Ihnen zu verlangen.
- <footnote>
- <para>Sicherheitsbewusstere Leute verzichten
- möglicherweise darauf, das Passwort des
- Client-Zertifikats in der
- <filename>servers</filename>-Laufzeitdatei
- abzulegen.</para>
- </footnote>
- </para>
+ </informalexample>
</sect3>
@@ -7288,11 +6999,11 @@
</sidebar>
- </sect1>
+ </sect1>
</chapter>
<!--
More information about the svnbook-dev
mailing list