Creating a user account on the slave

134 also allow you to create several accounts for several different VPNs, if different masters are all logging into the same slave. You might have this situation when there are several branch office masters setting up VPNs with one central office slave. For our purposes, well call the user account vpn1. Give it a password thats hard to crack, and it doesnt need to be easy to remember—were going to be using RSA authentication for the SSH login.

8.4.2.4 Setting up SSH authentication

Weve already gone through how to set up SSH on a system. Once you set up the SSH daemon to launch at startup, follow these steps to set up SSH authentication: 1. On the master host, set up a key pair for the root account using the ssh-keygen program. If one already exists, check to make sure no existing services are using it. If not, you might want to go ahead and set one up again in order to make sure the keys are not compromised. This process will create the HOME.sshidentity and HOME.sshidentity.pub files for root. When youre prompted for a passphrase, leave it blank and press Enter. Because the VPN script might start up while the machine is unattended such as after a remote reboot, we dont want it to have to enter the passphrase in order to connect with the SSH client. 2. Log into the slave as vpn1 or su to that user. Run ssh-keygen for that user. In that users home directory, create a .rhosts file with the hostname of the master master- gw and the account that the master is going to be logging in as—in this case its vpn1. 3. Next you want to add the slaves public host key to the roots known_hosts file on the master. The easiest way to do this is to run ssh to connect to the slave, and ssh will automatically ask you if you wish to add the slaves public key to the file, to which you respond yes. To add the masters public host key to vpn1s known_hosts file, you can either try to connect to it using the SSH client, or copy the key from etcssh_host_key.pub. 4. Next, copy roots public key from identity.pub on the master and put it in vpn1s authorized_keys file. At this point, we have .rhosts, RSA host, and RSA user authentication all enabled for this connection, providing maximum security. To further tighten security, we can edit the etcsshd_config file on both hosts and modify or verify the following entries: PermitRootLogin no StrictModes yes RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication yes PasswordAuthentication no AllowHosts master-gw.ora-vpn.com slave-gw.ora-vpn.com admin.ora-vpn.com The PermitRootLogin setting of no will prevent root from logging in to either system using SSH. A StrictModes of yes means that the SSH daemon will complain if a users home directory is world-writable. The next few entries control the types of authentication permitted: • Setting RhostsAuthentication to no which is the default means that rhosts authentication alone is not enough to allow a user to make an SSH connection. 135 • RhostsRSAAuthentication set to no means that rhosts authentication plus RSA host authentication isnt sufficient either. • Setting RSAAuthentication to yes which is the default means that RSA user authentication is allowed. • PasswordAuthentication set to no means that password authentication if RSA authentication fails isnt allowed. The AllowHosts option is usually commented out, but it can be enabled to allow SSH connections only from a specific host. In this case, the slave is allowing connections only from master.ora-vpn.com. On the master, you would set AllowHosts to allow slave.ora- vpn.com. This means that each machine will allow an SSH connection only from the other. Of course, if you disable telnet completely and allow the other VPN host to connect only via SSH, thats the only machine youll be able to connect for remote administration. Aside from the chosen remote host, all work will have to be done at the console. Alternatively, you can add other hosts, such as admin.ora-vpn.com in our example, or allow every host from your domain to connect with the wildcard .ora-vpn.com. At this point, you should be able to connect to the slave from the master as vpn1 using the SSH client. During this trial, you might want to keep a telnet session open on the slave in case there are problems. Try entering a command like this on the master, but with your slave in place of ours: ssh -l vpn1 slave-gw.ora-vpn.com It should log you in to the slave machine without asking for a password. If it fails, its probably due to an authentication error. Try running the same command, but add the -v option. That will give you excellent debugging output and show you whether its .rhosts, RSA host, or RSA user authentication thats failing.

8.4.2.5 Configuring sudo on the slave

The sudo program is set up much like the other programs, using configure, make, and make install. It is placed in usrlocalbin. In order to change the configuration file for sudo, called sudoers, you need to use the visudo tool, which can be run only as root. The visudo editor uses your selected editor vi by default, but will lock the file to make sure only one person is editing it, and will perform syntax checking against what the user is entering. It will automatically open sudoers when invoked. sudo only needs to be installed on the slave for the vpn1 account, since the VPN script will be run as root on the master. The reason is that vpn1 will have to eventually execute the route add command, which is privileged. Here are the lines to add to your sudoers file: Cmnd alias specification Cmnd_Alias VPN=usrsbinpppd,sbinroute User specification vpn1 ALL=NOPASSWD: VPN The lines beginning with the pound sign are comments and will be ignored. The first command sets up a command alias called VPN that contains the pppd and route programs. This parameter provides a convenient way to group multiple programs that you want to allow