SW Designs

My hosting companies recent upgrade from Virtuozzo Power Panel to HyperVM resulted in a change to how RAM usage is calculated (and therefore restricted).  Despite top telling I was only using ~80% of my RAM, after the upgrade I started receiving frequent emails from cron informing me that processes were running out of memory and I even had problems opening SSH connections to the server.

The only options I was offered by Tektonic support were to upgrade to a more expensive product or reduce my RAM consumption.  Neither were feasible, particularly as I had not changed anything.  Anyway a month later Tektonic corrected the problem by announcing a free 15% RAM and 30% disk space upgrade for all customers.  This is shown by the jump in unused RAM in the graph below.

Thankfully I’ve not any further problems since then, however I think I’ll keep the company I was going to migrate to, Linode, bookmarked.  They use Xen for virtualization which is the only such software that supports swap files meaning this problem almost guaranteed not to happen.

Since the Debian security advisory was published there has been plenty of discussion about who is to blame and how such a bug has gone unnoticed since September 2006. While they are important discussions that need to be had, I’ll focus on how to protect your Debian based PCs, laptops, servers, etc. First thing’s first, upgrade OpenSSH and the relevant packages.

$ sudo apt-get update
$ sudo apt-get upgrade

Where you have OpenSSH installed, the host keys must be regenerated.

$ sudo rm /etc/ssh/ssh_host_*
$ sudo dpkg-reconfigure openssh-server
Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ...
Restarting OpenBSD Secure Shell server: sshd.

SSHing onto the server will display a warning because the client’s host key in the known_hosts file does match what the server presents. Just delete the referenced line from known_hosts.

$ ssh server
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

If you use public key authentication you’ll need to regenerate those keys, remembering to remove the old entry from authorized_keys on the server. The same goes for SSL certs used by web servers.

After installing Xubuntu Hardy Heron on my laptop I found that ctrl+alt+del was not activating the screensaver. To understand why this happens we look at /usr/bin/xflock4 - the script that Xfce uses to enable a screensaver,

$ cat /usr/bin/xflock4
if ps aux  grep x[s]creensaver &gt /dev/null 2&gt&amp1 then
xscreensaver-command -lock
elif ps aux  grep gnome-[s]creensaver &gt /dev/null 2&gt&amp1 then
gnome-screensaver-command --lock
else
xlock $*
fi
exit 0

And manually running the script gives us,

$ xflock4
/usr/bin/xflock4: 28: xlock: not found

This means neither xscreensaver, gnome-screensaver or xlock are installed and running. Of the three, I prefer gnome-screensaver. This is already installed so we just need to make it run during login. Goto Xfce menu > Settings > Settings Manager > Autostarted apps > Add. Enter an appropriate name and set the command to gnome-screensaver.

It’s common practice to use self signed certs in development environments. Here’s how to do it for Lighttpd.

$ openssl req -new -x509 -keyout ~/cert.pem -out ~/cert.pem -days 365 -nodes
Generating a 1024 bit RSA private key
....++++++
...................................................................................................++++++
writing new private key to '/root/cert.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:GB
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:SW Designs
Organizational Unit Name (eg, section) []:SW Designs
Common Name (eg, YOUR name) []:*.sw-designs.co.uk
Email Address []:</code>
 
Move the cert to its new location,
 
<code>sudo mkdir /etc/lighttpd/private
sudo mv ~/cert.pem /etc/lighttpd/private
sudo chown -r root:root /etc/lighttpd/private/
sudo chmod -r 0600 /etc/lighttpd/private/

Finally load the cert in the Lighttpd config,

ssl.engine  = "enable"
ssl.pemfile = "/etc/lighttpd/private/cert.pem"
ssl.use-sslv2 = "disable"

Entering your password when SSHing onto remote machines gets very boring, very quickly. The good news that this is can be avoided by using public key authentication and without compromising security. In fact, this approach can prevent brute force attacks if password based authentication is turned off as well.

1. The first step is to generate a public/private key pair on the client machine. Due to the security problems with SSH-1, we’ll be creating SSH-2 keys.

$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/simon/.ssh/id_dsa):

Hit enter to accept the default file. Next we’re prompted for a passphrase, I suggest you don’t leave it empty unless you have a requirement for completely passwordless access.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/simon/.ssh/id_dsa.
Your public key has been saved in /home/simon/.ssh/id_dsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx simon@server

2. Now we add the public key from the client into the authorised keys file on the sever, creating the file if it doesn’t already exist. Multiple keys can be added file if necessary, just append them to the end of it.

$ cat ~/.ssh/id_dsa.pub  ssh server 'cat - &gt&gt ~/.ssh/authorized_keys'
simon@server's password:

Update: ssh-copy-id is a better why to do this,

$ ssh-copy-id -i .ssh/id_dsa.pub simon@server

3. Verify that the keys work. You should now be prompted for a passphrase instead of a password. If not, check that DSAAuthentication is enabled in /etc/ssh/sshd_config on the server.

$ ssh server
Enter passphrase for key '/home/simon/.ssh/id_dsa':

4. Okay, so we’re now using public key authentication, good times, but still having to enter a passphrase, bad times. By using ssh-agent, you just need to enter your passphrase once per session.

$ ssh-agent
Enter passphrase for /home/simon/.ssh/id_dsa:
Identity added: /home/simon/.ssh/id_dsa (/home/simon/.ssh/id_dsa)

Now you can just type ssh server and you will be automagically logged in to the remote machine.