Connection and authentication occurs before the CVS protocol itself is started. There are several ways to connect.
server |
If the client has a way to execute commands on the server, and provide
input to the commands and output from them, then it can connect that
way. This could be the usual rsh (port 514) protocol, Kerberos rsh,
SSH, or any similar mechanism. The client may allow the user to specify
the name of the server program; the default is | ||||||||
kserver | The kerberized server listens on a port (in the current implementation, by having inetd call "cvs kserver") which defaults to 1999. The client connects, sends the usual kerberos authentication information, and then starts the cvs protocol. Note: port 1999 is officially registered for another use, and in any event one cannot register more than one port for CVS, so GSS-API (see below) is recommended instead of kserver as a way to support kerberos. | ||||||||
pserver | The name pserver is somewhat confusing. It refers to both a generic framework which allows the CVS protocol to support several authentication mechanisms, and a name for a specific mechanism which transfers a username and a cleartext password. Servers need not support all mechanisms, and in fact servers will typically want to support only those mechanisms which meet the relevant security needs. The pserver server listens on a port (in the current implementation, by having inetd call "cvs pserver") which defaults to 2401 (this port is officially registered). The client connects, and sends the following:
The client must send the
identical string for cvs root both here and later in the
If the client wishes to merely authenticate without starting the cvs protocol, the procedure is the same, except BEGIN AUTH REQUEST is replaced with BEGIN VERIFICATION REQUEST, END AUTH REQUEST is replaced with END VERIFICATION REQUEST, and upon receipt of I LOVE YOU the connection is closed rather than continuing.
Another mechanism is GSSAPI authentication. GSSAPI is a
generic interface to security services such as kerberos. GSSAPI is
specified in RFC2078 (GSSAPI version 2) and RFC1508 (GSSAPI version 1);
we are not aware of differences between the two which affect the
protocol in incompatible ways, so we make no attempt to specify one
version or the other.
The procedure here is to start with ` | ||||||||
future possibilities |
There are a nearly unlimited number of ways to connect and authenticate.
One might want to allow access based on IP address (similar to the usual
rsh protocol but with different/no restrictions on ports < 1024), to
adopt mechanisms such as Pluggable Authentication Modules (PAM), to
allow users to run their own servers under their own usernames without
root access, or any number of other possibilities. The way to add
future mechanisms, for the most part, should be to continue to use port
2401, but to use different strings in place of ` |