Home Is Home: The Physical Practicalities - Smart Home Automation with Linux and Raspberry Pi - page 141

Chapter 5.) You can then additionally set up a second domain with access to your home automation web pages. You
will still secure these pages, naturally, but this is a good first step.
Although registering domain names is easy enough, it is not necessarily the best option when dealing with home
machines, because your IP might change when a DHCP lease is not renewed at the whim of the ISP, and you'd have
to wait another 24 hours for the DNS information to repropagate through the various DNS servers. Although this is
unlikely, even if you decide to power down the server every night, better solutions are available by using dynamic
DNS. The method assigns an arbitrary subdomain, from a known primary domain, to a given IP. Because subdomains
do not need to be propagated by DNS before they can be used, they have a more immediate effect and can be
registered for very little money—in most cases, zero.
One such service is available from dyndns.org . After registering (also free!), you can create your own subdomain
and point it to your home server. This subdomain can extend from one of several primary domains, such as
homelinux.net , mine.nu , or dnsalias.com . The T&C requires that you update this record periodically to ensure
it's still active, but this can be done automatically with appropriate routers or through a package such as ddclient .
This should be run periodically, either in daemon mode or from crontab, to keep their records up to date. The
configuration simply requires your login credentials for DynDNS and the subdomain names you want to update.

# /etc/ddclient.conf

daemon=600
use=web, web=checkip.dyndns.com/, web-skip='IP Address'
login=your-username
password=your-password
protocol=dyndns2
server=members.dyndns.org
my.homelinux.net

Because this is a DNS record, only the name is registered. It's still up to you to support the services. But this is
what you want, because it allows you to run your own servers for e-mail, the Web, SSH, and so on.
You can hide behind more curtains by providing access only through an external proxy—a proxy the existence
and login of which is known only to you. The first step is to prepare the hosts.allow file with the following:

sshd: LOCAL myhidden.privateserver.com

and add the paranoid inverse to hosts.deny :

sshd: ALL

As you can guess, when used in combination, this limits all SSH connections to those originating from the local
(192.168.x.x) network and those on an external server that might be a colocated server, work machine, or shell account.

N Note These rules can apply to all protocols, not just SSH, by changing sshd to ALL in the previous examples.

This approach is not without risk, however, because should your server become inaccessible for any reason,
you will be able to connect to it (and therefore solve the problem) only from the specified machines, which might be
difficult if you are on vacation.