- Need to read this document
- Many steps from the below recipe have been taken from Building Linux VPN's. For more indepth information read chapter 3, of this book.
- In order to keep everything isolated, I created a new user/group (sshvpn/sshvpn) on mia and zidler. Instructions for creating users using command line options can be found here
- Establish the options for having passwordless login. All the related Instructions to gain passwordless
ssh login for both SSH v1 and v2 can be found
here. I have used SSH v2 (with RSA), since it has a
lot more options.
Take a look at the /etc/ssh/ssh_config file, which manipulates how ssh will behave. Do a man on
ssh_config to find about all these options.
Below I have cat'ed our ~/.ssh/config file. Note: how I have disabled compression here. I will enable
it when i need to do other experiments.
The system wide comfiguration file is in /etc/ssh/ssh_config Host * Protocol 2,1 #Ciphers=blowfish-cbc Ciphers=aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc #MACS=hmac-sha1 MACS=hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 #Compression=yes #CompressionLevel=8
REMEBER THAT YOU SHOULD NOT PUT A PASSPHRASE FOR PROTECTING A PRIVATE SSH KEY. ELSE YOU WILL HAVE TO RUN ssh-agent AND ssh-add FOR PASSWORDLESS LOGIN - Set up SUDO, if you do not want
root to set up the VPN. In order to configure sudo, ONLY USE
visudo. Set up the EDITOR environtment variable to pico using the command
mia#>setenv EDITOR pico mia#>visudo
The sudoers file is listed below. More advanced options for sudo can be found here# sudoers file. # This file MUST be edited with the 'visudo' command as root. # See the sudoers man page for the details on how to write a sudoers file. # Host alias specification # User alias specification # Cmnd alias specification Cmnd_Alias VPN=/usr/sbin/pppd, /bin/kill, /sbin/route # Defaults specification # User privilege specification root ALL=(ALL) ALL # Uncomment to allow people in group wheel to run all commands # %wheel ALL=(ALL) ALL # Same thing without a password # %wheel ALL=(ALL) NOPASSWD: ALL # Samples # %users ALL=/sbin/mount /cdrom,/sbin/umount /cdrom # %users localhost=/sbin/shutdown -h now sshvpn ALL=NOPASSWD: VPN
- I have modified the following scripts (that came with the linux VPN book)
according to my personal requirements to automatically create a PPP-OVER-SSH VPN.
I felt the original was too bulky for me. If you need the original scripts, please visit the author's
web site.
This script also sets up routing information on both the client and the server. You can download the script from
here. A few things to note before going on:
Note the arguments for both client and server ppp process. They are reproduced below:
[More Information on PPP]
--SNIP-- CLIENT_PPPD_ARGS="noauth noccp novj novjccomp nopcomp noaccomp debug dump logfd 2 passive updetach \ name $vpn_network-client linkname $vpn_network pty" SERVER_PPPD_ARGS="noauth noccp novj novjccomp nopcomp noaccomp lock" --SNIP--A explanation of these arguments can be sought by using man pppd and is provided below:- noauth: It is not required to authenticate the peer. This argument has to be provided at both the client and the server.
- noccp, novj, novjccomp, nopcomp, noaccomp: These options will disable pppd from negotiating any compression at all.
Remove these options if you want to enable compression. In the presense of these options, pppd on client and server will
have the following negotiations:
sent [LCP ConfReq id=0x1 asyncmap 0x0 magic 0xb99a3976] rcvd [LCP ConfReq id=0x1 asyncmap 0x0 magic 0xa7ed8c60] sent [LCP ConfAck id=0x1 asyncmap 0x0 magic 0xa7ed8c60] sent [LCP ConfReq id=0x1 asyncmap 0x0 magic 0xb99a3976] rcvd [LCP ConfAck id=0x1 asyncmap 0x0 magic 0xb99a3976] sent [IPCP ConfReq id=0x1 addr 0.0.0.0] rcvd [IPCP ConfReq id=0x1 addr 192.168.254.201] sent [IPCP ConfAck id=0x1 addr 192.168.254.201] rcvd [IPCP ConfNak id=0x1 addr 192.168.254.200] sent [IPCP ConfReq id=0x2 addr 192.168.254.200] rcvd [IPCP ConfAck id=0x2 addr 192.168.254.200] local IP address 192.168.254.200 remote IP address 192.168.254.201
Without these options, pppd on client and server will negotiate compression as see by the following exhange.Connect: ppp0 <--> /dev/pts/8 rcvd [LCP ConfReq id=0x1 asyncmap 0x0 magic 0x87ecc7a1 pcomp accomp] sent [LCP ConfReq id=0x1 asyncmap 0x0 magic 0xdce8f6b2 pcomp accomp] sent [LCP ConfAck id=0x1 asyncmap 0x0 magic 0x87ecc7a1 pcomp accomp] rcvd [LCP ConfAck id=0x1 asyncmap 0x0 magic 0xdce8f6b2 pcomp accomp] sent [CCP ConfReq id=0x1 deflate 15 deflate(old#) 15] sent [IPCP ConfReq id=0x1 compress VJ 0f 01 addr 0.0.0.0] rcvd [CCP ConfReq id=0x1 deflate 15 deflate(old#) 15] sent [CCP ConfAck id=0x1 deflate 15 deflate(old#) 15] rcvd [IPCP ConfReq id=0x1 compress VJ 0f 01 addr 192.168.254.201] sent [IPCP ConfAck id=0x1 compress VJ 0f 01 addr 192.168.254.201] rcvd [CCP ConfAck id=0x1 deflate 15 deflate(old#) 15] Deflate (15) compression enabled rcvd [IPCP ConfNak id=0x1 addr 192.168.254.200] sent [IPCP ConfReq id=0x2 compress VJ 0f 01 addr 192.168.254.200] rcvd [IPCP ConfAck id=0x2 compress VJ 0f 01 addr 192.168.254.200] local IP address 192.168.254.200 remote IP address 192.168.254.201
- I am asssuming that we are using the following setup. mia
as the client and zidler as the server .
- The script can be used as follows:
sshvpn@mia:~/bin> sh -x ./ppp_over_ssh_vpn start vpn1
NOTE: "sh -x" is only used to provide debugging information. Do not use it if you want to script to execute quitely.
After the script is executed, do the following checks- use "ifconfig" to see if a new ppp interface "ppp0" has been set up. For e.g.
sshvpn@mia:~/bin> ifconfig ---SNIP--- ppp0 Link encap:Point-to-Point Protocol inet addr:192.168.254.253 P-t-P:192.168.254.254 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:5 errors:0 dropped:0 overruns:0 frame:0 TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:66 (66.0 b) TX bytes:72 (72.0 b) - use "netstat -rn" on both the client and the server machine to verify that the routing tables are updated.
For e.g. (Entries of interest are marked with ***)
sshvpn@mia:~/bin> netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.254.254 0.0.0.0 255.255.255.255 UH 40 0 0 ppp0*** 131.193.50.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0 192.168.1.0 192.168.254.254 255.255.255.0 UG 40 0 0 ppp0*** 192.168.0.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 40 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo 0.0.0.0 131.193.50.1 0.0.0.0 UG 40 0 0 eth0 ------------------------------------------------------------------------------ sshvpn@zidler:~> netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.254.253 0.0.0.0 255.255.255.255 UH 40 0 0 ppp0*** 131.193.50.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0 192.168.0.0 192.168.254.253 255.255.255.0 UG 40 0 0 ppp0*** 127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo 0.0.0.0 131.193.50.1 0.0.0.0 UG 40 0 0 eth0
- use "iptables" to verify that the forward chain has default behaviour of accept. If this is not set
then u will not be able to ping from one network to another. For e.g.
[sshvpn@mia bin]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT)*** target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere LOG all -- anywhere anywhere LOG level warning ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere LOG all -- anywhere anywhere LOG level warning Chain OUTPUT (policy ACCEPT) target prot opt source destination
- Finally use "ping" to check the connectivity.
- use "ifconfig" to see if a new ppp interface "ppp0" has been set up. For e.g.
- Finally to remove the connection use the following command.
sshvpn@mia:~/bin> sh -x ppp_over_ssh_vpn stop vpn1
This will automatically clear related entries in the routing table and stop pppd and the system should return to the initial state.
- The below diagram traces the path taken by a packet as it travels over the ppp-over-ssh tunnel.
- Each layer of protocol adds some bytes of overhead. This is illustrated in the above diagram. Note that
the SSH layer, has been shown to add "X" bytes of overhead. I am using
OpenSSH(3.5p1) implementation for the SSH protocol. This supports both
SSH1 and SSH2. I am concentrating only on SSH2.
To find out the overhead added by the SSH layer, one needs to read the standards published on IETF secsh working group web page. The appropriate documents to read is: SSH Transport Layer Protocol. - You will find that SSH bundles packet as:
4-byte packet_length 1-byte padding_length n1-byte payload; n2-byte random padding; to make [packet_length + Paddin_length + payload] a multiple of block_size used by the cipher. (min:= 4 Bytes) m-byte MAC (message authentication code); e.g. SHA1 (20 Bytes), MD5 (16 Bytes) - One can select the following cipher's and HMac's.
The below table gives an indication of the block size and the key size used
by different ciphers:
--------------------------- Cipher SSH Blk Key Ver. Sze Sze --------------------------- 3des 1 8 16 blowfish 1 8 32 3des-cbc 2 8 24 blowfish-cbc 2 8 16 cast128-cbc 2 8 16 arcfour 2 8 16 aes128-cbc 2 16 16 aes192-cbc 2 16 24 aes265-cbc 2 16 32 --------------------------- Court: From source code $HOME/temp/openssh-3.5p1/cipher.cThe below table gives an indication of the size of each MAC:--------------------------- MAC's Size (B) --------------------------- hmac-md5 16 hmac-sha1 20 hmac-ripemd160 20 hmac-sha1-96 6 hmac-md5-96 6 ---------------------------
- A suitable cipher and HMAC can be selected by specify the appropriate ciphers and HMACS
option in $HOME/.ssh/config file as i have shown below:
sshvpn@mia:~/.ssh> cat config Host * Protocol 2,1 #Ciphers=aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc Ciphers=blowfish-cbc #MACS=hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 MACS=hmac-sha1 --SNIP--
You can also find if your specified Cipher and MAC pair is being used, by using -v option with ssh and looking for the following lines:sshvpn@mia:~/.ssh> ssh -v sshvpn@zidler OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f --SNIP-- debug1: kex: server->client blowfish-cbc hmac-sha1 none debug1: kex: client->server blowfish-cbc hmac-sha1 none --SNIP--
- Let us assume that we are using aes128-cbc + hmac-md5. Suppose that the input to the SSH layer is
a packet of length 144 bytes, then you can calculate the total overhead added by SSH as follows:
- Add 4 + 1 = 5 Bytes of header to Packet. This gives 144 + 5 = 149.
- Find out what block size is used by the cipher from the table given above. In our case, since we are using aes128-cbc, the block size is 16 bytes.
- Calculate 149 % 16 = 5. Hence in order to make the packet an even multiple of 16, you will have to add either 11 bytes (to make it 160) or 27 bytes (to make it 176) etc. of padding. The exact amount of padding added is random, but the minimum is 4 bytes and maximum is 255 bytes.
- In this case, let us assume that we have added just 11 Bytes to make the packet to be of length 160 bytes, which is an even multiple of 16.
- Now add the HMAC. Find the length of the HMAC from the table above. Since we are using hmac-md5, the HMAC is of length 16 bytes.
- Thus we have a total packet size of 176 Bytes, which agress with out experimental results.
- Thus we conclude that the SSH layer adds a minimum of (4(packet len) + 1(padding len) + 4(padding) + 6(MAC=hmac-md5-96) = 15 bytes) and maximum of (4(packet len) + 1(padding len) + 255(padding) + 20(MAC=hmac-sha1) = 280 bytes).
- Assuming no compression mechanism is used in either PPP or SSH,
and using the cipher suite (aes128-cbc + hmac-md5), we conducted a series of experiments with
varying application input sizes. The input data for this experiment was totally random.
An example of such data is shown below:
seq_no: 0 Y%*i%|\NU]\Dw-5jOba4Q@D8`?5t#"iBFna^M1OF)t?6++f)m6ZIR:aOY3EvO1Tu!7UhI&0R6O%\uked#BIpvGARZfd+3; "Olq9Q3J@J5E(,2m,5KVA^}bLse2 4gcVI}C\ccB4*J[VTg(;YIyr.Gg/Z#C]Y)OBs{AXYU}&2Ut6w1+CG kn#zdA?D6H/ U&$lGwG9vgeg]7a+C@R]-\z)]=b=nGLEMQ31dtJ\^K_Wc\b(|Pe+I{N(;3EEtqjC^9nD/:)"|aeZ_)s2n ['i}\8D#.7)k2B\Vl2su4qThis data was generated using modudpgen, a synonym for Modified UDP generator and sniffed using ethereal.
The results are presented below: It is observed that the TCP/UDP/IP headers amount to a total of 110 Bytes, which is fixed. The rest is the overhead attached by the SSH layer.-------------------------------------------------------- Application Data Data on wire Overhead (No comp) -------------------------------------------------------- 100 242 142 275 418 143 350 498 148 502 658 156 613 770 157 750 898 148 849 1010 161 917 1074 157 1010 1170 160 1200 1346 146 -------------------------------------------------------- Average Overhead: 151.8 --------------------------------------------------------
- I enabled full compression at both the ppp and SSH layer. This can be done by NOT specifying
the following options to ppp (both client and server)
noccp novj novjccomp nopcomp noaccomp
and at ssh layer by specifying the following in the ~/.ssh/config file.--SNIP-- Compression=yes CompressionLevel=9 --SNIP--
- The input data for this experiment was totally random. An example of such data is shown below:
seq_no: 0 Y%*i%|\NU]\Dw-5jOba4Q@D8`?5t#"iBFna^M1OF)t?6++f)m6ZIR:aOY3EvO1Tu!7UhI&0R6O%\uked#BIpvGARZfd+3; "Olq9Q3J@J5E(,2m,5KVA^}bLse2 4gcVI}C\ccB4*J[VTg(;YIyr.Gg/Z#C]Y)OBs{AXYU}&2Ut6w1+CG kn#zdA?D6H/ U&$lGwG9vgeg]7a+C@R]-\z)]=b=nGLEMQ31dtJ\^K_Wc\b(|Pe+I{N(;3EEtqjC^9nD/:)"|aeZ_)s2n ['i}\8D#.7)k2B\Vl2su4qThis data was generated using modudpgen, a synonym for Modified UDP generator and sniffed using ethereal.
The experimental results, using the cipher suite (aes128-cbc + hmac-md5) are presented below:-------------------------------------------------------- Application Data Data on wire Overhead (full Comp) -------------------------------------------------------- 100 226 126 275 418 143 350 466 116 502 610 108 613 706 93 750 818 68 849 882 33 917 930 13 1010 1026 16 1200 1170 -30 -------------------------------------------------------- Average Overhead: 68.6 -------------------------------------------------------- - Using compressionm, it is not possible to estimate the amount of overhead, as the amount of compression really depends on the entropy in the data. It is entirely possible for the data on the wire to be lesser in size to the input data. For e.g. when we used an input data of size 1200 bytes (each having a value "S"), we found that the packet size on the wire was just 130 Bytes.
- PPP-over-SSH VPN tunnels, do not have inbuilt routing mechanisms. As a result the user
has to take care of establishing routes to remote networks. This can be done in the following two ways:
- Static routes can be set up within the script itself (as we have done) using the command:
route add -net network/netmask gw gateway-ip
Although this method is simple for small networks, it becomes exceedingly difficult to maintain such routes one your network reaches a decent size (> 5 nodes, say). Hence one should avoid using this method, unless you have a very small network. - Another way is to use a routing software that will set up/tear down the routes automatically. One such software to consider is Gnu Zebra with one of its components: OSPF. At the time of this writing, I could not find much documentation on how to configure zebra, and since I was not working with any complex network architectures, I preferred to use the first method. However, I do plan to include the steps to set up zebra in future.
- Static routes can be set up within the script itself (as we have done) using the command:
- The OpenSSH implementation of SSH that I am using does not provide any mechanism (AFAIK) to use arbitary algorithms for SSH operation. The standard documents, though, do mention that it should be possible to add extensibility to the SSH protocol. Read SSH architecture (Sec: 3.2).
- The PPP-over-SSH solution for forming VPN's is highly unscalable.
- For e.g. If a company has 'N' different sites, then it would be necessary to have O(N^2) point-to-point PPP-over-SSH links and each site will have to maintain an entry in the routing table for (N-1) other sites. I think a full mesh will be necessary in this case, as the complexity of maintaining any other network infrastructure will be prohibitively high.