Avoiding the remote host identification changed warning ssh'ing to localhost

If you run several virtual machines under VirtualBox and use port forwarding (Settings > Network > Advanced > Port Forwarding) to map its port 22 to a localhost port so that you can ssh to it, you will end up with several remote hosts all accessed from localhost but at different ports. In such a situation, if you have an older ssh client, you might end up with this well known warning when you try to connect:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

The reason is that older ssh clients only store the domain name or the IP address of the server in the ~/.ssh/known_hosts file. So there can only be one host key for localhost and when you connect to a different port there is a key mismatch. Newer ssh clients store the port number also and don't have this problem. You can fix this temporarily by deleting the host key entry but when you connect to another server it happens again.

I've seen solutions that suggest suppressing the host key check. There is another way. All addresses in the 127.0.0.0/8 subnet are localhost so you can use distinct IP addresses for each VM. For example in ~/.ssh/config you could have something like this:

Host centos64

Hostname localhost

        Port 2201

Host debian64

Hostname 127.0.0.2

        Port 2202

This way there are distinct host key entries for the two VMs and you will not get the dreaded clash and warning.

Once again, this is only necessary when using an older ssh client.

Setting event timezone in Lightning (Thunderbird)

This has been a solved problem since 2008 but it may not be obvious to everybody so I'm publicising it here.

You can set the timezone of individual events in Lightning. When you edit an event, there are timezone links next to the start and end times. You can see it in this page's screenshot. The link colour may not always stand out. Clicking on the link brings up a timezone chooser map where you can change the timezone of the event. If the start and end times are linked, you only need to change one. Also if you have used a foreign timezone before, a shortcut is provided.

It seems however, from limited testing, that for synced calendars such as Gcal, existing events have to be edited at both sides for the timezone to stick, even though the time is correct.

An essential feature for those of us who work or communicate across timezones, or have deadlines in other timezones, e.g. taking a MOOC.

Now if only the ICS files sent to me always had the correct timezone.

ping: icmp open socket: Operation not permitted, and capabilities

Last night I installed a SSD on my openSUSE 13.1 system, copied my root filesystem to it, and made it the boot volume. Afterwards it booted up very quickly. I went to bed a happy person.

This morning, while checking some network issues I used ping and got the error in the title. What happened!?

Checking the permissions on both the old filesystem and the new one revealed no differences.

-rwxr-xr-x 1 root root 43480 Nov 16 09:47 /usr/bin/ping

Was it supposed to be setuid? Let's see whether the package manager thinks it's installed correctly.

$ rpm -qf /usr/bin/ping
iputils-s20101006-23.4.1.x86_64
$ rpm -V iputils
/usr/bin/ping should be root:root 0755 "= cap_net_raw+ep". (wrong missing capabilities)

Ah, something was lost in the copying. Searching for capabilities revealed that they allow finer grained privileges than setuid. To fix I was supposed to run setcap. But there was no such utility installed, so I repaired the situation by reinstalling iputils instead of installing the libcap-progs package.

$ sudo zypper install -f iputils

And ping was back to normal.

Incidentally some posts claim that rsync preserves capabilities. I did use rsync to copy and yet the capability did not come across. I can find nothing in the manual page of rsync about this.

Here's a good introduction to capabilities.