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 at eldivino's password:
Linux eldivino 2.2.19 #6 Mon Jun 4 10:32:19 PDT 2001 i686 unknown
No mail.
vpn at 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 at 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 at 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. 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.
| |
| |
Free eBook: 
