Setting up the PPP daemon

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.