We need to set up the server to respond to the client's request to bring up the tunnel.
The incoming SSH VPN requests must be directed to a particular user on the server. For security and accountability, I recommend you use a dedicated user to field VPN requests. The following steps will set up a system user named "vpn" to do just that.
First, we create the user's account. Accounts come in two ranges: the system range (typically 100-999) and the regular user range (1000+). "--system" tells adduser to add the user in the system range and to give him /bin/false for the login shell. "--group" tells adduser to also create a group of the same name as the user, and to add the user to the group.
server# adduser --sytem --group vpn |
Since the vpn user needs to log in via ssh, change vpn's shell from /bin/false to /bin/bash in the /etc/passwd file. You can simply edit /etc/passwd using vi or any other decent text editor.
Create a password for the vpn user. It can (and should) be very complex, since you'll only type it a few times while setting up the VPN. After that, you'll never type it again.
server# passwd vpn Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully |
Now, try connecting to the server to ensure that you've created the account properly.
client% ssh eldivino.domain.com -l vpn vpn@eldivino's password: Linux eldivino 2.2.19 #6 Mon Jun 4 10:32:19 PDT 2001 i686 unknown No mail. vpn@eldivino:~$ |
It may take a while for ssh to connect if you don't have reverse DNS set up properly. You can fix that whenever you want. It will only delay bringing up the VPN -- it won't prevent it from working.
If it just stalls, then the ssh protocol is probably being dropped by a firewall between the two machines. Have a look at section Section 3.5 again.
It would be terrible to have to type in a password every time you wanted to bring the VPN link up, so we'll set up SSH's RSA authentication. Skip this section if you truly don't mind typing a password every time.
Ensure that the root account on the client machine has a public key in root's home directory (~/root/.ssh/identity.pub). If this file doesn't exist, then you must create it. As root, run ssh-keygen:
# ssh-keygen Generating public/private rsa1 key pair. Enter file in which to save the key (/root/.ssh/identity): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/identity. Your public key has been saved in /root/.ssh/identity.pub. The key fingerprint is: 15:61:57:7e:5c:26:91:09:5c:e6:10:b7:a1:74:bd:25 root@paradis |
Now, copy identity.pub to the vpn account's authorized_keys file on the server. You will almost certainly have to create this. As root, perform the following commands on the server:
server# cd ~vpn server# mkdir .ssh server# chown root.vpn .ssh server# chmod 755 .ssh server# cd .ssh |
Now, copy th the client's /root/.ssh/identity.pub file (it's only one line) to the server's ~vpn/.ssh/authorized_keys file. You can add more lines to authorized_keys, one for each client, if you want to allow multiple clients to connect.
server# chown root.vpn authorized_keys server# chmod 644 authorized_keys |
Now, become root on the client, and try SSHing to the server. You may or may not need to use the -P option, depending on how your client's firewall is set up. If port 22 is blocked on your client (not a bad idea if it's not running an SSH server), then -P tells ssh to use an unprivileged port even though it's running as a priveleged user.
client# ssh -P eldivino.domain.com -l vpn Linux eldivino 2.2.19 #6 Mon Jun 4 11:03:22 PDT 2001 i686 unknown No mail. vpn@eldivino:~$ |
There, we were just RSA-authenticated. Keep your private key (the client's ~root/.ssh/identity file) private! Anyone who has access to this file can log into the VPN account on the server.
pppd needs to run as root. However, on the server, we're running everything as the "vpn" user. How can the vpn user run pppd?
There are a number of ways of solving this problem. One is to use the suid bit, and arrange permissions by groups. However, this can get confusing and difficult to administer pretty fast, leading to unintentional security holes. Personally, I find the sudo utility to be a much better solution.
sudo gives ordinary users superuser powers, but only for a very limited set of commands. The system administrator gets to decide what commands are allowed and how much logging to perform. In this case, we want to allow the user "vpn" to run pppd with superuser privilege, but not be allowed to do anything else.
We need to edit sudo's configuration file, /etc/sudoers. To use proper locking, hopefully preventing accidents and race conditions, use the visudo command to edit /etc/sudoers. If you're not faimiliar with vi, see the VIM HOWTO.
server# visudo |
Add these two lines to the bottom of the file:
Cmnd_Alias VPN=/usr/sbin/pppd vpn ALL=NOPASSWD: VPN |
Now, verify that sudo is set up correctly. As the "vpn" user on the server, try running pppd using sudo:
server# su - vpn server$ sudo /usr/sbin/pppd noauth ~9}#ĄZ}!}!} }9}"}k} }r} }'}%}zt2-·}'}"} |
If you get a whole bunch of PPP garbage to the screen (like the last line above), this is good. It means that the vpn user is allowed to run pppd. You can now switch to another terminal to kill it off, or you can just let pppd finish on its own. It should give up trying to connect after 30 seconds or so.
However, if you get "bash: /usr/sbin/pppd: Permission denied" or some other sort of error, or it asks for a password, then sudo is probably not working. You'll need to try figure out what is going wrong. Verify that pppd is in /usr/sbin, and that you set up the sudoers file correctly.