alex 01/07/05 15:55:41
Modified: xdocs/site cvsonunix.xml
Log:
Fixed error in CVS example code. Reformatted quote from man ssh.
Other minor changes.
Revision Changes Path
1.4 +50 -45 jakarta-site2/xdocs/site/cvsonunix.xml
Index: cvsonunix.xml
===================================================================
RCS file: /home/cvs/jakarta-site2/xdocs/site/cvsonunix.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- cvsonunix.xml 2001/03/10 01:01:51 1.3
+++ cvsonunix.xml 2001/07/05 22:55:40 1.4
@@ -51,72 +51,77 @@
CVSROOT environment variable should be set without the :pserver:
argument. Depending on which shell you use, you need to set your
environment variables properly. You can also use the cvs -d argument in
-place of setting the CVSROOT.
+place of setting the CVSROOT.
</p>
-<source>
-CVS_RSH=/path/to/ssh
-cvs -d [EMAIL PROTECTED]:/home/cvs login
-</source>
-
<p>
-After you login, you can check out any of the source trees. The
-command to checkout source code is:
+As an example, in order to checkout the module "jakarta-site" in bash
+as CVS user "alex", you would use:
</p>
<source>
-cvs -d [EMAIL PROTECTED]:/home/cvs checkout module
+export CVS_RSH=/usr/bin/ssh
+cvs -d [EMAIL PROTECTED]:/home/cvs co jakarta-site
</source>
<p>
SSH will then ask you for your password to log into the machine.
-You can provide your password or follow these directions (copied
-from the ssh man page):
</p>
-<source>
-As a third authentication method, ssh supports RSA based authentication.
-The scheme is based on public-key cryptography: there are cryptosystems
-where encryption and decryption are done using separate keys, and it is
-not possible to derive the decryption key from the encryption key. RSA
-is one such system. The idea is that each user creates a public/private
-key pair for authentication purposes. The server knows the public key,
-and only the user knows the private key. The file
-$HOME/.ssh/authorized_keys lists the public keys that are permitted for
-logging in. When the user logs in, the ssh program tells the server
-which key pair it would like to use for authentication. The server
-checks if this key is permitted, and if so, sends the user (actually the
-ssh program running on behalf of the user) a challenge, a random number,
-encrypted by the user's public key. The challenge can only be decrypted
-using the proper private key. The user's client then decrypts the chal-
-lenge using the private key, proving that he/she knows the private key
-but without disclosing it to the server.
-
-ssh implements the RSA authentication protocol automatically. The user
-creates his/her RSA key pair by running ssh-keygen(1). This stores the
-private key in $HOME/.ssh/identity and the public key in
-$HOME/.ssh/identity.pub in the user's home directory. The user should
-then copy the identity.pub to $HOME/.ssh/authorized_keys in his/her home
-directory on the remote machine (the authorized_keys file corresponds to
-the conventional $HOME/.rhosts file, and has one key per line, though
-the lines can be very long). After this, the user can log in without
-giving the password. RSA authentication is much more secure than rhosts
-authen- tication.
-</source>
+<p>
+The <a href="./cvsindex.html">list of Jakarta modules</a> is on this
+site.
+</p>
<p>
-When ssh-keygen asks you for a password, just hit enter.
+Once you checkout a source tree, all CVS operations in that source tree
+do not require the <code>-d</code> argument.
</p>
<p>
-The list of modules are shown on <a href="./cvsindex.html">this
-page</a>.
+As an even more secure alternative to password authentication, follow
+these directions (copied from the ssh man page):
</p>
+<blockquote>
<p>
-Once you checkout a source tree, all CVS operations in that source tree
-do not require the <code>-d</code> argument.
+As a third authentication method, ssh supports RSA based
+authentication. The scheme is based on public-key cryptography: there
+are cryptosystems where encryption and decryption are done using
+separate keys, and it is not possible to derive the decryption key
+from the encryption key. RSA is one such system. The idea is that
+each user creates a public/private key pair for authentication
+purposes. The server knows the public key, and only the user knows
+the private key. The file <code>$HOME/.ssh/authorized_keys</code>
+lists the public keys that are permitted for logging in. When the
+user logs in, the ssh program tells the server which key pair it would
+like to use for authentication. The server checks if this key is
+permitted, and if so, sends the user (actually the ssh program running
+on behalf of the user) a challenge, a random number, encrypted by the
+user's public key. The challenge can only be decrypted using the
+proper private key. The user's client then decrypts the chal- lenge
+using the private key, proving that he/she knows the private key but
+without disclosing it to the server.
</p>
+<p>
+ssh implements the RSA authentication protocol automatically. The
+user creates his/her RSA key pair by running ssh-keygen(1). This
+stores the private key in <code>$HOME/.ssh/identity</code> and the
+public key in <code>$HOME/.ssh/identity.pub</code> in the user's home
+directory. The user should then copy the identity.pub to
+<code>$HOME/.ssh/authorized_keys</code> in his/her home directory on
+the remote machine (the authorized_keys file corresponds to the
+conventional <code>$HOME/.rhosts</code> file, and has one key per
+line, though the lines can be very long). After this, the user can
+log in without giving the password. RSA authentication is much more
+secure than rhosts authentication.
+</p>
+</blockquote>
+
+<p>
+When ssh-keygen asks you for a password, just hit enter.
+</p>
+
</section>
</body>
