[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