Fri, 27 Jan 2012
/Admin/SSH-SSL:
Passwordless Authentication with SSH
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[1] on the subject. For the basics, I prefer to
start with this article[2].
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[3]. 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 root@server.com:
scp /home/username/.ssh/id_rsa.pub root@server.com:
Go to server.com and append the new key to the authorized_keys:
ssh server.com
cd /root/.ssh/
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 root@server.com
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-pty
ie. 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 root@server.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 root@server.com 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 root@server.com will result in a password
prompt.
[1] http://wiki.rdiff-backup.org/wiki/index.php/UnattendedRdiff
[2] http://linuxgazette.net/104/odonovan.html
[3] https://members.nearlyfreespeech.net/ckoen/support/faq?q=SSHKeys#SSHKeys
posted at: 00:51 | path: /Admin/SSH-SSL | permanent link to this entry
Fri, 20 Jan 2012
/Admin/OpenVPN:
Basic OpenVPN as an Internet Gateway
Aka. How to bore through the Great Firewall if you do not want to use an SSH tunnel.
This[1] is the OpenVPN documentation, but it is not altogether straight-forward to read, and it is
missing some necessary detail.
This[2] will get OpenVPN basically working and connected for you. First create your keys:
<![CDATA[
cd /usr/share/doc/openvpn/examples/easy-rsa/2.0
. ./vars
./clean-all
./build-ca
./build-key server
./build-key <client>
./build-dh
]]>
Here I would add a warning from [1] 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 134.33.0.0 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 [2] 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 [1], 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 [2], 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[3] very interesting post....)
[1] http://www.openvpn.net/index.php/open-source/documentation/howto.html
[2] https://www.debian-administration.org/article/Connecting_to_office_network_using_OpenVPN_tunnel
[3] http://www.hermann-uwe.de/blog/howto-using-openvpn-on-debian-gnu-linux
posted at: 03:58 | path: /Admin/OpenVPN | permanent link to this entry
/Linux/misc:
Running and Installing Debian from a USB Stick
So unbelievably easy[1]:
cat debian.iso > /dev/sdX
sync
I grabbed the latest net install[2] 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....
Update:
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.
[1] http://www.debian.org/releases/stable/i386/ch04s03.html.en
[2] http://www.debian.org/CD/netinst/
posted at: 01:51 | path: /Linux/misc | permanent link to this entry
Sun, 15 Jan 2012
/Admin/virtualization/virtualBox:
Debian Host and Guest
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
modprobe vboxdrv
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:
linux-image-3.1.0-1-686-pae
linux-headers-3.1.0-1-686-pae
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:
/etc/init.d/virtualbox-guest-utils start
and now
# 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.)
posted at: 01:10 | path: /Admin/virtualization/virtualBox | permanent link to this entry
