How to use SSH keys to login to your server without giving a password -- perhaps contra-inuitively, this kind of passwordless login is usually more, not less, secure then a password login. (Not to mention convenient and time-efficient....)
Say we want to login to server.com from our desktop without a password. The rdiff-backup wiki provides a somewhat obtuse and hard-to-read article on the subject. For the basics, I prefer to start with this article.
On your desktop, run:
ssh-keygen -b 4096 -t rsa -f /home/username/.ssh/id_rsa
Do not enter a pass-phrase!! Leave it blank
(Note: we are creating a 4096 bit key here as recommended by nearlyfreespeech.net. It is possible that some situations will require a 1024 bit key, and this key will not be useable in that situation. It is possible to have multiple keys, which may be invoked by the "ssh -i" option, for instance.)
Now copy the public key "id_rsa.pub" to firstname.lastname@example.org:
scp /home/username/.ssh/id_rsa.pub email@example.com:
Go to server.com and append the new key to the authorized_keys:
cat ../id_rsa.pub >> authorized_keys
Restrict access to these keys on both your desktop and your root@server:
chmod -R go-rwx ~/.ssh
Test to verify you are not prompted for a password. In a terminal on your desktop, try a verbose ssh to server.com:
ssh -v firstname.lastname@example.org
If there are problems and you are prompted for a password (you should not be) the -v output should give you some clues.
In some situations, one can make SSH key logins even more secure. For instance, on server.com, add some security directives to a particular key in /root/.ssh/authorized_keys by pre-pending the following:
command="rdiff-backup --server --restrict-read-only/",no-port-forwarding,no-X11-forwarding,no-ptyie. in /root/.ssh/authorized_keys the key in qestion now contains the following, ALL ON ONE LINE, and note the single space before "ssh-rsa":
command="rdiff-backup --server --restrict-read-only /",no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AA ... uqdswe= user@desktop
"no-pty" explicitly forbids terminal priveleges. "command" here restricts the session to running one and only one command: "rdiff-backup --server --restrict-read-only".
Now if you try to ssh to email@example.com from a terminal, your terminal will just lock-up and stop responding. If you really do want to allow this (a terminal ssh to firstname.lastname@example.org without a password) just remove the "command" and "no-pty" directives from the server.com /root/.ssh/authorized_keys file.
Note that this will only work from the account "username" on your desktop machine where you have generated a /home/username/.ssh/id_rsa file and then passed the public key to server.com. Trying to ssh from any other desktop account to email@example.com will result in a password prompt.
Aka. How to bore through the Great Firewall if you do not want to use an SSH tunnel.
This is the OpenVPN documentation, but it is not altogether straight-forward to read, and it is missing some necessary detail.
This will get OpenVPN basically working and connected for you. First create your keys:
cd /usr/share/doc/openvpn/examples/easy-rsa/2.0 . ./vars ./clean-all ./build-ca ./build-key server ./build-key ./build-dh
Here I would add a warning from  that when creating your certificates above you must enter something at the "Common Name" prompt. My first time I just accepted all the defaults and got a connection error when I tried to start OpenVPN on my client. The second time, with a "Common Name" on the server certificates, everything just worked.
Then distribute the keys to server and client(s) per the references.
This will get the VPN client to the VPN server. However, we want to route *all* network traffic on the client through VPN and out to the internet. There are two components to this: some additional OpenVPN configuration, and some routing configuration on the server. On my VPN server, this is my /etc/openvpn/server.conf:
port 1348 proto udp dev tap ca ca.crt cert server.crt key server.key # This file should be kept secret dh dh1024.pem server 10.10.10.0 255.255.255.0 # vpn subnet ifconfig-pool-persist ipp.txt keepalive 10 120 comp-lzo user nobody ; group nobody persist-key persist-tun verb 10 mute 20 client-to-client client-config-dir ccd "route 220.127.116.11 255.255.0.0" ; push "route 192.168.1.0 255.255.255.0" # home subnet push "redirect-gateway def1" push "dhcp-option DNS 10.10.10.1"
This should be the same as in  except that "group nobody" line did not work on my Ubuntu Lucid server for some reason, and the last two "push" lines are what is needed on the server end to tell connecting clients to redirect all network traffic to the VPN. (Though I am not convinced that last dhcp line is having any effect on my Debian box at the moment....) Also, per , note that if your network interface is DHCP, it may die periodically because it is unable to communicate with your DHCP server.
On my VPN client, this is my /etc/openvpn/client.conf:
client dev tap proto udp resolv-retry infinite # this is necessary for DynDNS nobind user nobody ; group nobody persist-key persist-tun ca ca.crt cert x60s.crt key x60s.key comp-lzo verb 4 mute 20
which is the same as in , except for commenting out "group nobody", which did not work on my Debian Testing client machine.
Now for routing on the server. What a PITA. I tried at some length to get raw iptables to do the job, but in the end turned to my old faithful, firehol. Here is my /etc/firehol/firehol.conf on my server, which enables the routing of traffic between tap0 (VPN) and eth0 (internet):
version 5 # interface eth0 internet interface eth0 internet protection strong 10/sec 10 server "https http icmp ssh" accept server openvpn accept server ident reject with tcp-reset client all accept interface tap0 vpn server all accept client all accept router internet2vpn inface eth0 outface tap0 masquerade reverse client all accept server ident reject with tcp-reset
(After the fact, I ran into this very interesting post....)
So unbelievably easy:
cat debian.iso > /dev/sdX
I grabbed the latest net install ISO, did the above, popped it into my new laptop, hit F12 during boot to get the boot menu, and picked the USB option. Never had such a swift and painless install....
And then there was Ubuntu Lucid. Not so easy. The ISO will not boot from USB per the above. After a bit of flailing around, it seems the easiest way (and so far the only way) that has worked for me is to use usb-creator, which is packaged with Lucid. And only works with X, there is no console version.
Yes, that means you need a running Lucid desktop to do this. Lame. The package that needs to be installed is usb-creator-gtk. Note that you can invoke it from the following menu:
System --> Administration --> Startup Disk Creator
but that did not work for me either, there were errors. What I did was installed the sux package, logged into root in a terminal by invoking sux, and then invoked usb-creator-gtk as root. Then it worked, and the USB stick booted.
At least on Debian, there is one thing that is constantly breaking in my VirtualBox (VB) installation: missing kernel headers. The symptom is, that after a new kernel comes in, VB suddenly will not work any longer. It seems particulary insidious on the guest Debian OS, because "all" that stops working are certain conveniences, like (what I was just sorely missing) the ability to copy and paste between host and guest OS. I found it very easy to assume that something was just broken, when in fact all that was missing was the kernel headers package.
So once and for all, here is the drill for getting VB working properly on both host and guest....
On the host, this is the list of modules I have installed:
virtualbox virtualbox-dkms virtualbox-guest-additions virtualbox-guest-additions-iso virtualbox-ose virtualbox-ose-dkms virtualbox-ose-qt virtualbox-ose-source virtualbox-qt virtualbox-source
On the host, if VB is not working and
does not find your VB kernel driver, ie.
FATAL: Module vboxdrv not found.
you are almost certainly missing headers, ie. there should be a headers package installed that exactly matches your current kernel:
Install it and all should be well. On the Debian guest OS, things are only slightly different. Here are my current VB modules on the guest:
virtualbox-guest-dkms virtualbox-guest-source virtualbox-guest-utils virtualbox-guest-x11 virtualbox-ose-guest-source virtualbox-ose-guest-utils virtualbox-ose-guest-x11
if you cannot copy and paste between host and guest (my recent symptom) and the vboxguest kernel module is missing, same drill: install your headers. Then:
# ps -ef | grep -i vbox clayton 1641 1 0 18:47 ? 00:00:00 /usr/bin/VBoxClient --clipboard clayton 1650 1 0 18:47 ? 00:00:00 /usr/bin/VBoxClient --display clayton 1655 1 0 18:47 ? 00:00:00 /usr/bin/VBoxClient --seamless
you can see all the things that were not working perfectly before. ("Clipboard" being the shared clipboard whose absence meant my copying and pasting was not working.)
One final tweak to get sound working on the guest OS:
apt-get install pulseaudio pavucontrol
Then start pavucontrol, and in the output section, turn off the mute button. (I did try installing a couple of simpler mixers to see what was going on, but they would not even start for some reason. And in any case, in my experience, pulseaudio works well and I do not mind having it around.)