Today I started playing around with Apples’ Darwin Calendar Server . I’ve attempted this before in the past and I didn’t get very far with it. However, when I took up the reigns again today, I encountered a completely different problem that took me a little bit of time to resolve. In short, I had incorrect SSH keys in my local client to connect to my server. All of you SSH/Unix gurus out there probably can skip this, but this may help some nubies.
A little background: I have an Ubuntu server that serves as my utility server for the house. It’s primary job is to act as a big file server for the house. Since I’ve always wanted a lab in the house to play with the latest technologies – I installed VMWare server on that Ubuntu server as well. Whenever I want to play with some new software or whatever, I can quickly create a new server or client VM very quickly.
Since installing the VMWare server, I have a couple of VMs that I constantly run – a Windows Primary Domain Controller (acts as my primary DNS server as well), a Ubuntu server running Gallery 2 for the family’s web album, and a clean XP machine to run my finances (only connects to the net to pay bills). Any other VM I create and destroy on the fly. One such VM was the Calendar server VM.
In essence the first time I played with Apple’s Darwin Calendar Server, I created a VM with a server called Calendar. I did all sorts of bad things to this server in an attempt to get the server started. To make my life easier, I installed OpenSSH on the server so that I could simply SSH to it from my Ubuntu workstation.
I abandoned the server and have since come back to the project with a little more energy. So the first thing I do is kill off the VM and recreate the Calendar server. I used the same name as I didn’t want to take the 5 minutes to change the DNS server with new information.
After install all the necessary software, including OpenSSH, I got an error similar to the following when I attempted to access the Calendar server remotely via SSH:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The DSA host key for shell.sourceforge.net has changed, and the key for the according IP address 66.35.250.208 is unknown. This could either mean that DNS SPOOFING is happening or the IP address for the host and its host key have changed at the same time. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 DSA host key has just been changed. The fingerprint for the DSA key sent by the remote host is 4c:68:03:d4:5c:58:a6:1d:9d:17:13:24:14:48:ba:99. Please contact your system administrator. Add correct host key in /home/username/.ssh/known_hosts2 to get rid of this message. Offending key in /home/username/.ssh/known_hosts2:4 DSA host key for shell.sourceforge.net has changed and you have requested strict checking.
oops… I was the administrator and I didn’t know what to do! If I was using Windows and a tool like Putty, this would be trivial as I already know how to ‘fix’ this problem. Since I’m now using an Ubuntu workstation, and I was using the included ssh client, I had no idea what to do.
In essence, my local known_host table, located in my .ssh subdirectory and is responsible for capturing the keys of all known hosts that I’ve exchanged keys with, had an incorrect key for the new Calendar server. To make matters worse, the known_host file is hashed – which means you really just can’t take a text editor to it without knowing what you are really doing. I didn’t know how to recreate the key, ask for a new one, or what to do next…
After much Googling, I broke down and read the manual. The utility I needed to use was the ssh-keygen tool. One of the parameters for the tool is to remove keys for a particular server.
It seemed that I was saved! I simply executed:
ssh_keygen -r calendar
I didn’t get an error, and the system reported back that it had backed up my known_host file to boot! Great! I attempted to ssh into the calendar server again. This time I got a different set of prompts – which I happen not to capture – but in general it allowed me to create a new key. Wonderfully great! However, now each time I log into the calendar server, I get an error saying that the key is wrong and that I have two entries in my file for the same server!
It appears that the keys can be generated for either the server name or it’s IP address. I had created the originate entry using the server’s IP address rather than the name calendar. So I needed to remove that entry as well. To ensure I did everything correctly I execute the remove command for every variation of the server name and IP I could think of:
ssh_keygen -r calendar ssh_keygen -r calendar.<domain-name> ssh_keygen -r 192.168.1.77
Then I ssh back into the calendar server again, and was able to create a new key and everything has been working great since.
Hope this has helped someone out!
-JT