[svnbook commit] r1278 - in trunk/src/en: . book

sussman svnbook-dev at red-bean.com
Wed May 11 14:08:36 CDT 2005

Author: sussman
Date: Wed May 11 14:08:35 2005
New Revision: 1278


* src/en/book/ch06.xml (SSH configuration tricks): new section, taken
     from ghudson's notes/ssh-tricks.

* TODO:  remove to-done.

Modified: trunk/src/en/TODO
--- trunk/src/en/TODO	(original)
+++ trunk/src/en/TODO	Wed May 11 14:08:35 2005
@@ -116,12 +116,6 @@
         (FITZ) new chapter 9 section.
-  - With svn 1.1, it's now possible to set up svn+ssh using just one
-    Unix account on the server.  The book should perhaps document this
-    way of setting up svn+ssh.  See notes/ssh-tricks for details.
-        (BEN) will add this to chapter 6 section on svn+ssh://.
   - check that all the new 1.1 command switches are documented in ch09.
     See http://subversion.tigris.org/svn_1.1_releasenotes.html for list.

Modified: trunk/src/en/book/ch06.xml
--- trunk/src/en/book/ch06.xml	(original)
+++ trunk/src/en/book/ch06.xml	Wed May 11 14:08:35 2005
@@ -842,6 +842,129 @@
+    <sect2 id="svn-ch-6-sect-3.5">
+      <title>SSH configuration tricks</title>
+      <para>It's not only possible to control the way in which the
+        client invokes <command>ssh</command>, but also to control
+        the behavior of <command>sshd</command> on your server
+        machine.  In this section, we'll show how to control the
+        exact <command>svnserve</command> command executed
+        by <command>sshd</command>, as well as how to have multiple
+        users share a single system account.</para>
+      <sect3 id="svn-ch-6-sect-3.5.1">
+        <title>Initial setup</title>
+        <para>To begin, locate the home directory of the account
+          you'll be using to launch <command>svnserve</command>.  Make
+          sure the account has an SSH public/private keypair
+          installed, and that the user can log in via public-key
+          authentication.  Password authentication will not work,
+          since all of the following SSH tricks revolve around using
+          the SSH <filename>authorized_keys</filename> file.</para>
+        <para>If it doesn't already exist, create the
+          <filename>authorized_keys</filename> file (on Unix,
+          typically <filename>~/.ssh/authorized_keys</filename>).
+          Each line in this file describes a public key that is
+          allowed to connect.  The lines are typically of the
+          form:</para>
+  ssh-dsa AAAABtce9euch.... user at example.com
+        <para>The first field describes the type of key, the second
+          field is the uuencoded key itself, and the third field is a
+          comment.  However, it's a lesser known fact that the entire
+          line can be preceded by a <literal>command</literal>
+          field:</para>
+  command="program" ssh-dsa AAAABtce9euch.... user at example.com
+        <para>When the <literal>command</literal> field is set, the
+          SSH daemon will run the named program instead of the
+          typical <command>svnserve -t</command> invocation that the
+          Subversion client asks for.  This opens the door to a number
+          of server-side tricks.  In the following examples, we
+          abbreviate the lines of the file as:</para>
+  command="program" TYPE KEY COMMENT
+      </sect3>
+      <sect3 id="svn-ch-6-sect-3.5.2">
+        <title>Controlling the invoked command</title>
+        <para>Because we can specify the executed server-side command,
+          it's easy to name a specific <command>svnserve</command>
+          binary to run and to pass it extra arguments:</para>
+  command="/path/to/svnserve -t -r /virtual/root" TYPE KEY COMMENT
+        <para>In this example, <filename>/path/to/svnserve</filename>
+          might be a custom wrapper script
+          around <command>svnserve</command> which sets the umask (see
+          <xref linkend="svn-ch-6-sect-5"/>).  It also shows how to
+          anchor <command>svnserve</command> in a virtual root
+          directory, just as one often does when
+          running <command>svnserve</command> as a daemon process.
+          This might be done either to restrict access to parts of the
+          system, or simply to relieve the user of having to type an
+          absolute path in the <literal>svn+ssh://</literal>
+          URL.</para>
+        <para>It's also possible to have multiple users share a single
+          account.  Instead of creating a separate system account for
+          each user, generate a public/private keypair for each
+          person.  Then place each public key into
+          the <filename>authorized_users</filename> file, one per
+          line, and use the <option>--tunnel-user</option>
+          option:</para>
+  command="svnserve -t --tunnel-user=harry" TYPE1 KEY1 harry at example.com
+  command="svnserve -t --tunnel-user=sally" TYPE2 KEY2 sally at example.com
+        <para>This example allows both Harry and Sally to connect to
+          the same account via public-key authentication.  Each of
+          them has a custom command that will be executed;
+          the <option>--tunnel-user</option> option 
+          tells <command>svnserve -t</command> to assume that the named
+          argument is the authenticated user.  Without
+          <option>--tunnel-user</option>, it would appear as though
+          all commits were coming from the one shared system
+          account.</para>
+        <para>A final word of caution: giving a user access to the
+          server via public-key in a shared account might still allow
+          other forms of SSH access, even if you've set the
+          the <literal>command</literal> value
+          in <filename>authorized_keys</filename>.  For example, the
+          user may still get shell access through SSH, or be able to
+          perform X11 or general port-forwarding through your server.
+          To give the user as little permission as possible, you may
+          want to specify a number of restrictive options immediately
+          after the <literal>command</literal>:</para>
+  command="svnserve -t --tunnel-user=harry",no-port-forwarding,\
+           no-agent-forwarding,no-X11-forwarding,no-pty \
+           TYPE1 KEY1 harry at example.com
+      </sect3>
+    </sect2>
@@ -856,10 +979,10 @@
       network server that Subversion can leverage.  Via a custom
       module, <command>httpd</command> makes Subversion repositories
       available to clients via the WebDAV/DeltaV protocol, which is an
-      extension to HTTP 1.1 (see <systemitem
-      class="url">http://www.webdav.org/</systemitem> for more
-      information.) This protocol takes the ubiquitous HTTP protocol
-      that is the core of the World Wide Web, and adds
+      extension to HTTP 1.1
+      (see <systemitem class="url">http://www.webdav.org/</systemitem>
+      for more information.) This protocol takes the ubiquitous HTTP
+      protocol that is the core of the World Wide Web, and adds
       writing—specifically, versioned
       writing—capabilities.  The result is a standardized,
       robust system that is conveniently packaged as part of the

More information about the svnbook-dev mailing list