[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
Modified:
trunk/src/en/TODO
trunk/src/en/book/ch06.xml
Log:
* 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>
+ <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>
+
+<screen>
+ ssh-dsa AAAABtce9euch.... user at example.com
+</screen>
+
+ <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>
+
+<screen>
+ command="program" ssh-dsa AAAABtce9euch.... user at example.com
+</screen>
+
+ <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>
+
+<screen>
+ command="program" TYPE KEY COMMENT
+</screen>
+
+ </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>
+
+<screen>
+ command="/path/to/svnserve -t -r /virtual/root" TYPE KEY COMMENT
+</screen>
+
+ <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>
+
+<screen>
+ command="svnserve -t --tunnel-user=harry" TYPE1 KEY1 harry at example.com
+ command="svnserve -t --tunnel-user=sally" TYPE2 KEY2 sally at example.com
+</screen>
+
+ <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>
+
+<screen>
+ command="svnserve -t --tunnel-user=harry",no-port-forwarding,\
+ no-agent-forwarding,no-X11-forwarding,no-pty \
+ TYPE1 KEY1 harry at example.com
+</screen>
+
+ </sect3>
+
+ </sect2>
+
</sect1>
@@ -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