Windows Anonymous

It's easy to take networking for granted; just plug your PC into a modem or router (or, ahem, "find" your neighbor's wireless connection) and voila, instant Drunken-Facebooking. If you're old-school and remember a time before teh interwebs (think the acoustic-coupler modem), however, then you get excited about different ways to connect one computer to another. What's even cooler is stuff like tunneling, virtual private networks (VPNs), and encryption. Yes, really. Oh, shut up, you know it's cool.

Now that we're (mostly) all adults and the most high-tech networking we do anymore is getting Grandma's AOL account to quit fighting with Windows Firewall, it is in all seriousness a fun (and practical) diversion (network hacking, not AOL...My grandmother's 83 and can use a computer; she can go with any provider she feels like spending money on as far as I'm concerned.) For instance, how about accessing your machine from a remote location? How about doing it securely? Maybe even using the GUI.

How about all 3, all at the same time? Ohhhh, yeah!

Many of you are familiar with SSH or at least heard of it. Stands for Secure SHell and is exactly that; opens a terminal window (shell) on the local machine, connected to a remote machine with encryption to shield the data being transferred from prying eyes/machines. From there you can type commands and administer the remote machine. Then you have VNC (Virtual Network Computing) which, in a nutshell, is a way to remotely control another computer through its GUI. Both of these things are available free and open, they're both platform-independent, and there's even a way to tunnel VNC over SSH, in theory giving you the best of both worlds. It can be cumbersome, however; it's really flexible, but if you're not on a fast connection it can be slow (and with hardware limitations in can reach the point of unusability in a few cases). It works, but there's another way to do it, called FreeNX.

The NX methodology uses SSH for security as well, but handles things a little differently. First, it authenticates the SSH connection with a generic "nx" user that you create on the server. Then the "real" username is authenticated throught the thus-created SSH tunnel. Cool, no? NX itself is made up of two parts: the first is called nxproxy and runs on both the client and server. It compresses and/or caches most of the data, so it uses less connection bandwidth; always a good thing. The second is called nxagent which works the same way as Xnest (a nested X server, for those who don't know) and runs just on the client so the data doesn't have to make as many "round-trips" (i.e. you do something at the client, which goes to the server to actually be done, and back to the client to show you what just happened).

It gets better: You can suspend and resume login sessions. Also, NX can be a proxy server for a standard VNC connection if, for instance, the machine with which you're trying to connect doesn't have an NX client on it. Best of all, once everything has bee ndone and cached, it provides near-local speed.

Want to learn how to do this? Of course you do. First, get/update your OpenSSH install via whatever package manager you use; many Linux distros have it as part of their core installs but stranger things have happened. Then you have to (gasp) configure it. SSH has 2 config files, one for general settings and one for the daemon, SSHD:

# $OpenBSD: ssh_config,v 1.25 2009/02/17 01:28:32 djm Exp $
# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Host *
# ForwardAgent no }
# ForwardX11 no }*** uncomment these and change "ForwardX11" to yes
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes ***uncomment
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0 ***uncomment and change this to something longer, but not too long
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22 ***I would personally change this, every decent scanner automatically scans port 22 looking for SSH
# Protocol 2,1 ***change this to just "2", version 1 is no longer considered secure
# Cipher 3des
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1, This e-mail address is being protected from spambots. You need JavaScript enabled to view it ,hmac-ripemd160
# EscapeChar ~
# Tunnel no ***uncomment and change to yes
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
HashKnownHosts yes
StrictHostKeyChecking ask

This is just the stock ssh_config file with the minimum changes required to get NX to play nice; you may want to increase security at your own
discretion (and I absolutely recommend reading up on the subject). Then you have the sshd_config:

# $OpenBSD: sshd_config,v 1.75 2007/03/19 01:01:29 djm Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

#Port 22 ***uncomment and change to whatever you change it to in ssh_config
#Protocol 2,1 ***Just like the other one, get rid of the ",1"
ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/sshhostkey
# HostKeys for protocol version 2
HostKey /etc/ssh/sshhostrsa_key }
HostKey /etc/ssh/sshhostdsa_key } ***uncomment these

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 1h }
ServerKeyBits 768 } ***uncomment these and change SeverKeyBits to 1024 (or higher if you know what you're doing)

# Logging
#obsoletes ~QuietMode and ~FascistLogging
#SyslogFacility AUTH }
#LogLevel INFO } ***uncomment

# Authentication:

#LoginGraceTime 2m }
#PermitRootLogin yes } ***uncomment and change PermitRootLogin to 'no' unless you're really brave/stupid or know what you are doing
#StrictModes yes }
#MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes ***uncomment
#AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/sshknownhosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no ***uncomment, duh

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options #KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ~ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, ~PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
#UsePAM no ***uncomment and change to 'yes'
AllowUsers YOUR_USER_NAME nx ***add this line
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem sftp /usr/lib/ssh/sftp-server

Again, these are just the changes necessary to get NX running properly; you may (and again, I strongly encourage you to) read up on SSH security practices.

Now, you have to edit your hosts.allow file. It should be in /etc.

# let everyone connect to you...bad idea unless you're just testing
sshd: ALL
# OR you can restrict it to a certain ip
sshd: 192.168.0.1
# OR restrict for an IP range
sshd: 10.0.0.0/255.255.255.0
# OR restrict for an IP match sshd: 192.168.1.

Then in /etc/hosts.deny:

ALL: ALL: DENY

If sshd is already running you will need to restart it after making these (and any other) changes.

Next, get the NX server. This will depend on your distro, most have it in their repos under "FreeNX" (there is also a completely-GPL'ed version called openNX). Go to the NoMachine website and get a client. As it happens, NoMachine owns the code and brought it to market, so we have them to thank for open-sourcing the good parts. Might not sit well with Stallman but you can't win 'em all. Anyway, do the deed on whatever you'll use for the remote client hardware (laptop, secondary machine, etc). You may have to configure the NX server (in /path/to/NX/etc/node.conf) depending on your distro it might already be configured on install, especially if you got it as a package through your distro's repo. Transfer the key from the server to the client (you have the option of letting the NX server generate the stock one or using your own). Configure the client to use the right IP address & port, and don't forget to open the right port in your router/firewall (you can test things before going live with it behind a router).

Below is a stack o' links to get you started. It's fun and it's useful at the same time. Y'know, kind of like Linux.

http://www.nomachine.com/download.php: The NoMachine download page

http://www.ubuntugeek.com/how-to-install-freenx-server-and-client-in-ubuntu-9-10-karmic.html: Ubuntu how-to (for 9.10 but should work for 10.04)

http://openfacts2.berlios.de/wikien/index.php/BerliosProject:FreeNX_-_FAQ: The BerliOS page (which has a bunch of links on its own)

http://wiki.zenwalk.org/index.php?title=HOWTO_Install_FreeNX: Zenwalk how-to

http://wiki.centos.org/HowTos/FreeNX: CentOS how-to (and by extension Red Hat)

http://opennx.sourceforge.net/: OpenNX at SourceForge

http://code.google.com/p/neatx/: Neatx, a GSOC-sponsored NX server