Secure remote access to your desktop

Accessing your home server safely can be problematic, especially if you don’t have a fixed IP address, but with Linux, DynDNS, PAM, and NX Free you can create a safe remote access path to your machine.

A few months ago, I had to travel from my hometown of Montevideo, Uruguay, to New York. As I would be staying abroad a few weeks, I had to make sure I could access my home server safely. Despite Linux’s stability, I had to allow for my family having problems back home, and I couldn’t depend on giving instructions over the phone or by messaging.

I had to solve three problems to get everything running properly. First, I have an Asymmetric Digital Subscriber Line (ADSL) connection without a fixed IP address, which means my address can change, so I needed to be able to access my machine without knowing its address. Second, I can use SSH, but I know many people try attacks against machines that have the SSH port open, so I didn’t want my box to become an open target. Finally, I had heard about NoMachine’s NX Free Edition and wanted to try it out, but I had to make sure I did so safely.

Access a machine without a fixed IP

Not having a fixed IP address is a problem, but there’s an easy solution: DynDNS from Dynamic Network Services. This free service allows anybody to have a subdomain pointing to a computer with a changing, variable IP address. You simply install a small update client that keeps the hostname up to date with the client’s current IP address by notifying a central server each time the address changes. With many modern routers, you can even do without the client by configuring the router to do the notification by itself.

Go to the DynDNS site, sign up for a free account, and pick a domain (I picked remotekereki.homelinux.com). Finally, follow instructions to get the DDclient program, a short Perl script that keeps DynDNS up to date. Installing DDclient is easy: Just get the code, extract it to /usr/sbin (you’ll have to work as root), and edit /etc/ddclient/ddclient.conf to provide details about the site:

pid=/var/run/ddclient.pid
daemon=600
protocol=dyndns2
use=web, web=support.easydns.com/utils/get_ip.php
server=members.dyndns.org
login=yourOwnUserAccount
password=yourOwnPasswordyourOwnDomainName

As root, I ran chkconfig ddclient on followed by /etc/init.d/ddclient start, and I was ready and on my way. To verify that everything was really working, I tried ping remotekereki.homelinux.com and got an answer, which meant my address was available from anywhere in the world. First problem solved!

Secure your SSH access

A pluggable authentication module (PAM) is the key to greater flexibility regarding security. It used to be that the only way to create authentication was to have a user enter a password, then check that it matched the official password stored in the /etc/passwd file. Now, many other methods have appeared, including replacements for the /etc/passwd file, smart cards, and other hardware devices. Instead of rewriting all the programs to support these methods, you can install a PAM, and the necessary checks will be performed transparently.

I wanted to add some restrictions to access, and that meant adding a line at the bottom of my /etc/pam.d/sshd file:

#%PAM-1.0
auth     include        common-auth
auth     required       pam_nologin.so
account  include        common-account
password include        common-password
session  include        common-session
account  required       pam_access.so

The pam_access module implements added security controls based on the /etc/security/access.conf file. I edited it in order to specify who could access my machine:

+ : ALL : 192.168.
+ : remote1776 : ALL
+ : nx : ALL
- : ALL : ALL

The first line means that anybody (“ALL”) can log in to my machine from within the internal network at home. The second line allows the remote1776 user to access my machine from anywhere in the world, and the third line grants a similar right to the nx user that NX Free uses. The final line is a catch-all that disables access to anybody not specifically included in these lines.

That remote1776 user is an account with minimum rights that I created just to allow myself entry to the machine, so I could then execute su and work as myself or even root, if needed. If somebody guesses the correct password for remote1776, he’ll still have to work at guessing the password for other, more useful, users; it’s an extra barrier to pass before an intruder can do serious damage.

Now you need to configure SSH to use all of this. I edited /etc/ssh/sshd_config to include:

Port 16949
Protocol 2
PermitRootLogin no
MaxAuthTries 3
UsePAM yes

Note that these lines are all over the file; you’ll have to look around for them. The first line changes the SSH standard, well-known port (22) to a different number, so it will be harder for potential intruders to guess. Take care not to pick an already used port. I also opened this port in my firewall.

The protocol 2 line avoids using a somewhat weaker protocol. The third line is almost self-explanatory: I didn’t want anybody to be able to log in as root; let’s make life harder for hackers! Allowing only three tries before a time-out throws a wrench in brute-force attacks. Finally, the last line makes SSH use the PAM configuration.

All of this meant I had to restart ssh with /etc/init.d/sshd restart, and could from now on run ssh remote1776@remotekereki.homelinux.com:9622 in order to access my machine; that’s a long command!

Use NX Free

After having done all of this, getting NX Free to work with the added restraints was a breeze. NX Free implements its own security methods, but I added a couple of tweaks. First, I added the nx user to the list of allowed users. Second, when I defined the connection, I changed its standard port (22) to my new one (16949). That’s all I had to do. Of course, you’re taking advantage of all the installed infrastructure, but it’s nice not having to do much extra work for added security, isn’t it?

Learning how to do all this was a bit of work, but getting everything to work together was reasonably easy and efficient. I used my desktop machine from New York with no hassles, fixed a couple of problems that my family had, and survived all that time with my machine “in the open” with no intrusions.