Previous | Home | Purpose | Linux | Products | Legality | Schools | Downloads | Contact | Next
You will require:
Throughout this document, the calling system will be named bob and the answering system will be named gabrielle.
If the root user on bob does not have a passwordless login on gabrielle, make it so. The most secure convenient way of doing this is to add the public key of bob's root user to the ~/.ssh/authorized_keys file of gabrielle's root user. For example,
[root@bob /root]#ssh <~/.ssh/id_dsa.pub gabrielle cat >>.ssh/authorized_keys
You will need to type in gabrielle's root password. This presumes that ssh has been used by gabrielle's root user (ie, the /root/.ssh directory exists with appropriate permissions etc); if not, clock on to gabrielle, type ssh localhost and then Ctrl-C out of it again. If bob's root user has no public key, then use ssh-keygen to make one like this:
[root@bob /root]#ssh-keygen -t dsa
This makes a DSA key pair. RSA keys (in file ~/.ssh/identity.pub) are also acceptible but imply the use the older (version 1) ssh protocol.
That was the setup done. Hard, wasn't it? (-: Now start your VPN in one line:
[root@bob /root]#pppd noauth 192.168.33.1:192.168.33.2 \
pty 'ssh gabrielle pppd notty noauth'
Another difficult task completed. You might like to record the PID of a component of your VPN so you can shut it down without disturbing any other PPP links on the machine:
[root@bob /root]#echo $! >/var/run/vpn.pid
You can shut down the link with kill $(cat /var/run/vpn.pid) or all links with killall pppd. Nota Bene: Killall does different things on different systems, so while this is a fine idea on Linux or Irix, for example, it's a very, very bad idea on a BSD system like DEC UNIX or FreeBSD. Also, your system may record PIDs of running services in a different directory.
If the VPN crosses one or more slow links (such as a modem), it is worthwhile adding the -C option to the ssh command to allow ssh to compress traffic before sending it across the VPN.
If the addresses used in this working example fall within a subnet used elsewhere in your organisation, change them (for example, to 172.17.2.172:172.17.2.171) to help in the avoidance of routing conflicts.
It is possible to set up VPNs that can be brought up as required by users. The security implications of having, for example, a firewall-peircing VPN up full time can be a bit daunting.
I strongly recommend making pppd group-owned by a special group of which users with VPN capability then become members, and turning off its world-execute bit. Perhaps a future version of pppd will have finer grained access control (for example, a configuration option to use a secrets file from the invoking user's home directory), but for now this is it.
In our example, we will make a link for a user named jim from bob to a specially-created VPN user on gabrielle. Because the local pppd is (probably) set SUID-root, you will need to push root@bob's public key across to the authorized_keys file of gabrielle's VPN user, rather than jim's public key.
Create a file /etc/ppp/peers/gabvpn on bob, containing this:
192.168.33.1:192.168.33.2 name bobVPN remotename gabrielleVPN auth require-pap nodefaultroute idle 1800 nopersist pty 'ssh -C vpn@gabrielle /usr/sbin/pppd call bobvpn'
Create a file /etc/ppp/peers/bobvpn on gabrielle, containing this:
192.168.33.2:192.168.33.1 name gabrielleVPN remotename bobVPN auth require-pap nodefaultroute notty
Create or add to a file /etc/ppp/pap-secrets on bob, this line:
gabrielleVPN bobVPN c()mm()nS3kr1t
Create or add to a file /etc/ppp/pap-secrets on gabrielle, this line:
bobVPN gabrielleVPN c()mm()nS3kr1t
Create a new user bobvpn on gabrielle. Make sure that the caller's public key (root@bob if pppd is SUID-root, else jim@bob) is added to bobvpn@gabrielle's ~/.ssh/authorized_keys; at this point, the bobvpn account doesn't actually have to have a password (have fun bruteforcing that!), so you can edit his /etc/shadow entry to something non-useful like `!!'.
Start the vpn by (as jim@bob) typing:
pppd call gabvpn
The option `idle 1800' shuts down the VPN if there is no traffic for 30 minutes. This is an excellent idea for systems which don't allow users to kill SUID-root pppd sessions.
The option `asyncmap 0' may improve performance if your pppd has a different default.
On old, exceptionally slow machines where security is not a problem, you can implement this in a similar fashion using rsh instead of ssh. Modern (gigahertz-class as at April 2002) System will not notice the load imposed by a few encrypted sessions.
Troubleshooting often works best from the middle out, but in this case the most effective approach seems to be step by step from the caller's end.
If you would like us to read email for USD$1000 per page, payable in advance, send it here.