It has been probably close to a decade that I run a small server at home. At first it was only because I could not find a web hosting company that would serve my fcgi libwt apps at an affordable price. Then I added this blog to it. In the meantime I added a lot of other stuff as well. One of the more important things became ssh. Not only for remote shell sessions, but also for securely copying files and tunneling. In fact I use ssh tunnels instead of a more traditional VPN.
Discovery
Static IP addresses are expensive in Switzerland. So I used dyndns from the start. At first the free offering, and then switched to a paid plan long before they discontinued the free offering. Just last week I received a note that they grabed the annual fee from my (scheduled to be deactivated) credit card. Generally I strongly dislike services that automatically grab money from my accounts. They didn’t even mention that the fee doubled. That’s one side of the story, the other is that dyndns is an American company. They could take my domain name hostage without even telling me. So there has to be a better alternative. In fact there is one. It’s good technology wise, but not generally available to the unintroduced yet.
DyName for namecoin
I wrote about namecoin in a previous blog post. One of its main uses is a censorship resistant domain name registration. And the simple python script from DyName is to namecoin what dyndns and ddclient are to traditional domain names. Just prepare your registered name to include a dd entry, edit your config file, and call the script periodically from cron. That way you separate the private key where your name is registered from the hot wallet on the server. My provider used to reassign new ip addresses more frequently, now it’s about once every two months I would guess. The transition with namecoin was very smooth the last two times. I have a script that queries namecoin for the current ip address and then connects. There are dns resolvers and browser plugins or even public dns servers that would resolve namecoin domains. My experience with them was not as smooth as with the namecoin core itself. But I’m sure these parts will improve as well. So, with namecoin we have high confidence, that the ip address is correct that we are connecting to, but it can’t protect against man in the middle attacks. SSH has means to protect from that. The ssh client has a list of known ip addresses or host names and corresponding key fingerprints. But after an ip address change, there is no entry for the new destination, so ssh prints an error message and refuses to connect until you accept to add a new entry to your known_hosts file.
ssh known hosts
When you search for the error with your preferred search engine, you’ll find advices to delete offending lines in your known_hosts file. This of course is not what we need here. Just accepting to add a new entry the next time you connect would circumvent the protection against MITM that ssh provides. Since we already have the key fingerprint from the previous address, there is another more secure solution. If you have only one entry in your known_hosts file, you can skip the next few lines. Maybe you know which fingerprint is valid, for example because the file already contains a couple of lines with the same key fingerprint because the ip address changed a couple of times, and you just accepted it.
If you are not sure, which fingerprint you need, ask the server what it provides:
$ ssh-keyscan 85.3.164.135 # 85.3.164.135 SSH-2.0-OpenSSH_6.7p1 Ubuntu-5ubuntu1 85.3.164.135 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBE7WE5vtqSxUnQRX5CjOzEzUAdewqHRV5MXcSCQcylcKanpnDHRE4yVlEn770MFP6EfJ61ukdNYMDnSO9eoRiZY=
Now search for this fingerprint in your known_hosts file, and copy the whole line. On the new line, you replace the first hash with the actual new ip address in clear text. You could leave it like that, but you can also hash it with the following command.
$ ssh-keygen -H -f ~/.ssh/known_hosts
After writing all this I started wondering if it would be possible to keep the host key on an external hardware device like a NitroKey or a YubiKey. I already keep my client key for authenticating to the ssh server on one of these. That’s something to find out in a future post maybe.
Leave a Reply