Combining Authentication and Access

Combining authentication and authorization by IP address can be a little tricky because you don't want hosts that are listed by IP addresses to be asked for passwords, or users with passwords to be rejected because their IP address is rejected. There is an implicit "authenticate" rule at the end of cvsupd.access. If your client hasn't been blocked out by an explicit "deny" rule based on an IP address, you'll be allowed to authenticate. No special configuration is required.

In the example cvsupd.access file shown previously, I explicitly denied access to all IP addresses that were not in the list. If you wanted to give other users a chance to authenticate, you would list IP addresses that may always connect, and explicitly reject smaller blocks that you know you will never connect from. Here's a commented example:

...............................................................................................

#allow anyone inside our company to connect +192.168.0.0/16

#allow anyone from our sister company to connect +10.10.0.0/16

# users from here can never connect −24.0.0.0/8

...............................................................................................

In this example, systems with an IP address beginning with 192.168 or 10.10 could always connect. Computers with an IP address beginning with 24. could never connect, even if they had a username and password. If a computer with none of the above IP addresses tries to connect, it will be able to try a username and password.

This gives you complete control over access to your mirror.

137