CyberKnights

Modern tools.
Traditional dedication.

Previous | Home | Purpose | Linux | Products | Legality | Schools | Downloads | Contact | Next

Instant VPN, just add penguin (v0.1)

Ingredients

You will require:
Root access to two working Unix systems connected by IPv4 (normal) networking (Mandrake Linux 8.2 was used for testing); and

A working and recent PPP daemon; this will probably need to be installed SUID root unless you want to run your VPN only as root user on each end, your mileage will vary from system to system depending on the Unix and how it was set up (pppd version 2.4.1 was used for testing); and

A working and recent SecureSHell daemon and client (for testing, we used OpenSSH version 3.1p1).

Truly Instant

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.

Formal Instant

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

Amen.

Notes

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

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.

Does ssh work, sans password, from the caller to the answering account? If the `caller' is effectively root (as a SUID-root pppd is), can root on the calling node ssh sans password to the answering user?

Can the answering user run pppd? You may need to add a path to the invokation of pppd (in the pty line of the caller's options file), for example, to run it as /usr/sbin/pppd. Running pppd by hand as the answering user should result in a bunch of rubbish being spat out in the course of a minute or so. Try the command `reset' if your console becomes confused by this, or `echo -e \\33c'.

Is authentication complete and effective? Check the system logs (/var/log/messages on many systems) for errors. You may have to add the `debug' option to one or both PPP options files to see error messages, and/or change the syslog configuration. Does the link work with `noauth' options all around and the `auth' and `require-pap' options removed?

Is your firewalling setup permitting traffic (at each end) to and from the PPP link and addresses?

In your enthusiasm to try things out, have you raised a score of links, and wound up with traffic for the VPN being routed through a defunct ppp network device? If there are no other PPP links up, kill off all copies of pppd and then try once more.

Credits

Adam Davin <badger AT arach DOT net DOT au> - fix typoe

Bob <bob AT contact DOT omen DOT net DOT au> - testing, find presumption

Last changed: 23/04/2002, 08:09:30

Translate into

If you would like us to read email for USD$1000 per page, payable in advance, send it here.