Uwe Hermann - dyndnshttp://www.hermann-uwe.de/taxonomy/term/1952/0
enUpdated DIY Dynamic DNS solution HOWTOhttp://www.hermann-uwe.de/blog/updated-diy-dynamic-dns-solution-howto
<p>I've just updated my <a href="http://www.hermann-uwe.de/blog/diy-secure-pseudo-ddns-setup-using-ssh">DIY secure pseudo-DDNS setup using ssh</a> article/HOWTO a bit, in order to make it simpler to set up (no more extra scripts required) and a bit more secure (by using <strong>command=</strong> and <strong>no-port-forwarding,no-X11-forwarding,no-agent-forwarding</strong> in the <strong>/home/user/.ssh/authorized_keys</strong> file, for instance).</p>
<p>If you've considered employing such as solution please revisit <a href="http://www.hermann-uwe.de/blog/diy-secure-pseudo-ddns-setup-using-ssh">the article</a> for updated instructions.</p>
http://www.hermann-uwe.de/blog/updated-diy-dynamic-dns-solution-howto#commentsddnsdebiandiydnsdyndnslinuxopenvpnscriptsecuresecuritysshvpnSat, 02 Aug 2008 19:40:58 +0200Uwe Hermann1360 at http://www.hermann-uwe.deDIY secure pseudo-DDNS setup using sshhttp://www.hermann-uwe.de/blog/diy-secure-pseudo-ddns-setup-using-ssh
<p>Here's a quick HOWTO for setting up your own secure pseudo-<a href="http://en.wikipedia.org/wiki/Dynamic_DNS">dynamic DNS (DDNS)</a> server.</p>
<p>It's not a "real" DDNS service, i.e. you won't be able to use standard DNS tools or protocols to talk to the server, but it covers 98% of all functionality I expect from a service such as <a href="http://en.wikipedia.org/wiki/Dyndns">DynDNS</a> or <a href="http://www.dmoz.org/Computers/Internet/Protocols/DNS/DNS_Providers/Dynamic_DNS/">similar ones</a>: It tells me the IP address of a certain box which doesn't have a static IP address (e.g. my home-server).</p>
<h3>Requirements</h3>
<p>You'll need:</p>
<ul>
<li>A Linux box with dynamic IP address (dial-up modem/DSL), I'll call it <strong>homeserver</strong> from now on. This is the box whose public IP address I want to be able to find out.</li>
<li>A <strong>public</strong> Linux box with static IP address (or known DNS name) where you have a user account and ssh access. I'll call this box <strong>publicserver</strong>.</li>
</ul>
<h3>Setup</h3>
<p>On the <strong>homeserver</strong>:</p>
<ul>
<li>Add a non-root user account (e.g. <strong>user</strong>) just for the purpose of this mechanism: <strong>adduser user</strong>. The user doesn't need any special permissions.</li>
<li>Create an ssh key <strong>with an empty passphrase</strong> for the user: <strong>ssh-keygen -t rsa -b 4096</strong>. This is required as you'll want to run ssh commands via cronjob later.</li>
<li>
Add a cronjob which runs a random command such as <strong>ls</strong> regularly (as <strong>user</strong>), e.g. once per 10 minutes:<br />
<strong><code><br />
5,15,25,35,45,55 * * * * user ssh -x user@publicserver ls<br />
</code></strong><br />
The command to run (e.g. ls) doesn't really matter at all, more on that later.
</li>
</ul>
<p>On the <strong>publicserver</strong>:</p>
<ul>
<li>Add a non-root user account (e.g. also named <strong>user</strong>) just for the purpose of this mechanism: <strong>adduser user</strong>. The user doesn't need any special permissions.</li>
<li>Add the public ssh key (<strong>/home/user/.ssh/id_rsa.pub</strong>) of <strong>user@homeserver</strong> to the <strong>publicserver</strong>'s <strong>/home/user/.ssh/authorized_keys</strong>, so that the homeserver user can login on the remote publicserver without password (i.e. non-interactively). We'll also limit which ssh commands this user can run using the <strong>command</strong> keyword in <strong>/home/user/.ssh/authorized_keys</strong> file:<br />
<strong><code><br />
command="echo $SSH_CLIENT | cut -d \" \" -f 1 > /home/user/homeserverip.txt &amp;& chmod 644 /home/user/homeserverip.txt",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa AAAAAAAAAA...AAAAAAA user@homeserver<br />
</code></strong><br />
In the above example <strong>AAA...AAA</strong> is the public key, <strong>command</strong> specifies which command should be run if this user "logs in" via ssh, and we use some other options such as <strong>no-port-forwarding,no-X11-forwarding,no-agent-forwarding</strong> to minimize what this user can do via ssh.
</li>
</ul>
<p>So to summarize: the homeserver's user simply executes the above commands on the remote publicserver, which in turn abuses the <strong>$SSH_CLIENT</strong> environment variable which contains the public IP the ssh connection was coming from (which is exactly what we're looking for). We store that IP in the <strong>homeserverip.txt</strong> file, which will always contain the latest-known IP address of the homeserver (because of the cronjob).</p>
<h3>Getting the current homeserver IP address</h3>
<p>You can now retrieve the current IP address of your homeserver easily from anywhere (e.g. from your laptop when you're in another, possibly hostile network) in order to connect to your homeserver:</p>
<pre>
$ ssh -x otheruser@publicserver cat /home/user/homeserverip.txt
</pre><p>
To make this a bit more convenient you can add a shell alias (e.g. into <strong>~/.bashrc</strong>):</p>
<pre>
alias homeserverip='ssh -x otheruser@publicserver cat /home/user/homeserverip.txt'
</pre><p>
Or, to conveniently login to your homeserver as <strong>johndoe</strong>:</p>
<pre>
alias homeserverlogin='ssh -x johndoe@`ssh -x otheruser@publicserver cat /home/user/homeserverip.txt`'
</pre><h3>Conclusion, advantages</h3>
<p>This may not be the most elegant solution, and it has a number of drawbacks when compared to services such as DynDNS, but it's sufficient for me and it also has some advantages:</p>
<ul>
<li>You're not dependent on the DDNS service provider. For instance DynDNS recently changed their policy to only allow <strong>one update per 28 days</strong>, which totally sucks. They then disabled the service completely until I updated my <a href="http://ddclient.sf.net">ddclient</a> config and contacted them, i.e. I wasn't able to connect to my homeserver for quite a while, which also sucks.</li>
<li>The ssh-based solution is secure and encrypted, in contrast to some other DDNS services, which only allow unencrypted HTTP-based connections (yes, some do allow https/SSL connections).</li>
<li>This solution doesn't require in-depth DNS server config knowledge, neither does it require a DNS server you control. You only need a (non-root) ssh account on a public server (or virtual server).</li>
</ul>
<p>Personally I'm currently using this mechanism for two things, more might follow:</p>
<ul>
<li>Connect to my homeserver via ssh.</li>
<li>Get the homeserver's IP address so I can update my <a href="http://openvpn.net/">OpenVPN</a> client config file on my laptop (I use my homeserver as OpenVPN server).</li>
</ul>
<p>So far it works pretty nicely.</p>
<p><strong style="color:red">Update 2008-06-24:</strong> Various fixes and simplifications. SSH key must be password-less. Don't run cronjob once per minute, that's overkill.<br />
<strong style="color:red">Update 2008-07-02:</strong> Simplify setup by removing the need for extra scripts. Limit the commands the user can perform via ssh in the <strong>authorized_keys</strong> file. Make the RSA keys 4096 bits strong.</p>
http://www.hermann-uwe.de/blog/diy-secure-pseudo-ddns-setup-using-ssh#commentsddnsdebiandiydnsdyndnslinuxopenvpnscriptsecuresecuritysshvpnTue, 24 Jun 2008 15:56:59 +0200Uwe Hermann1349 at http://www.hermann-uwe.de