SECURE NETWORK REMOTE ADMINISTRATION USING SSH & VNC HOW-TO

Sirio Balmelli – Linux System Admin

PURPOSE

I wanted a secure method of administering my network from away as if I was at my desk, and also the ability to view and debug users in real time using VNC on their desktops directly.

In the spirit of cooperation and Open Source, if you discover something about this that you feel would improve the setup, feel free to jot down a line or two.

DISCLAIMER

I am not an SELinux developer. This means that if you work for the NSA and you are reading this, you had better be. In other words, I consider this system secure, absolutely – but I may have left something out, or deliberately enabled some settings that allow some nasty hacker to take over my network. This is how my machines are configured, but this same configuration may crash you machine and destroy years of data, who knows. Whatever you do with this information is up to you – no liability on my part.

BACKGROUND

You should know something about networks and ports. If not, god help you (just joking – one good place to read up on this at is fedorasolved.org – they have some excellent data on networking).

In getting more familiar with all those weird spooky things that live inside the linux command line, I found an excellent guide called “LINUX SYSTEM ADMINISTRATION” by gbdirect. I unfortunately forgot where I downloaded it, but all praise to them because it was great, and I hope you find it on google.

In this how-to, I describe commands to be input in the command line by writing them in italics. Any variables (information you have to input yourself) are written inside brackets like [this]. For example if I say [host] I mean for you to put 192.168.4.27 or mypc depending on what addresses your network uses and if you have DNS name resolution (a whole 'nother kettle of fish – if you are doubtful, stick to IP addresses).

GENERAL INFORMATION

I administer a small business network that sits at the other end of a DSL router – nothing fancy. The data my business deals with is slightly sensitive, so I had to be convincing to get permission from my superiors in order to create any external access at all. Here is how I did it.

The firewall on my router is of course enabled. There is only one cable going out of my router and that is to my IPCop box in the server room. There is an excellent IPCop how-to on howtoforge, so look it up if you want.

Inside my network, I have several windows PCs and a few OS X macs as well. My server runs FC 8, updated daily (you do update, right?).

Before I started wanting out of my office, I was perfectly content to sit at my server and debug users that needed it using VNC. I installed VNC on all of the windows clients in the domain and voila'.

INSTALLING VNC ON WINDOWS CLIENTS DESKTOPS

VNC is a free download. Use google. When you install it on one of your PCs, install only the server, not the viewer (you don't want the company users VNCing around to each other etc. etc.) and make sure to register it as a system service (so you can get to the computer even a user is not logged in. Avoid making desktop and start menu shortcuts for cleanliness' sake.

Once installed, you will see a white square in the right-hand side of your windows start bar. Double click that and you can change VNC's settings. One thing to do is set a password – this is not one of those things that is optional because tightVNC (the client you will use in connecting to your desktops) won't work unless you have a password (or so I read - I never tried).

On my machines, I also checked the option to disable local inputs while I am logged in (so I can get my job done no matter how much panic the end user is experiencing) and to drop the wallpaper when sending (lightens the load a bit and breaks the monotony – it's always either Brad Pitt or George Clooney).

Before you go anywhere, open up port 5900 TCP in the windows firewall or in Norton or whatever. If in doubt whether a port is open, run nmap -PN [host] of the machine that you just installed VNC server on. Just to get the theory straight, the machine whose desktop you are viewing, in VNC terms, is the server, while you, my friend, are the client.

ACCESSING FROM YOUR LOCAL SERVER, INSIDE YOUR SUBNET

From the local Linux Server (lets call it server1.mycompany.local) you should find an icon called VNC in the Internet section of your main menu. That is, if you are running a GNOME desktop on Fedora Core 8. In case you are not part of that small percentage, open up a terminal and type vncviewer [host]”. The net result is you should get a prompt asking for the VNC password you set.

If you get an error, try,

ping [host] to see if you can get to the computer and if so try

nmap -PN [host] to see if port 5900 is open.

if still no go, then vnc is not running on the remote machine.

When things go right, you will get the user's desktop inside a window.

At this point you may be disappointed by VNC in general – and you are right. VNC leaves something to be desired, even on a fast local network. However, I will later elaborate on ways to tighten up VNC so it is feasible to use over a modem or DSL connection – when you connect to your computers from Hawaii, or wherever you're going with your laptop.

SETTING UP YOUR SERVER RECEIVE SSH CONNECTIONS

There are many tutorials covering SSH in great detail. I think SSH is one of the coolest things that ever happened in the world of networking and is IMHO a must-learn.

Verify SSH is installed. on the command line, type ssh and you should get a list of options. If not, use a package manager to install it (like apt-get or yum). If you prefer to compile things yourself, you should probably be writing how-tos for me instead of reading this one.

Verify the ssh daemon is running. A daemon is the Linux equivalent of a Windows system service. It runs in the background and does a specific task whenever called upon. In your command line, type ps -e | grep sshd and if you get any output, then you are good to go.

In Fedora Core (with which I am most familiar) the easiest way to manipulate system services is using the service command. For example, service sshd status is self-explanatory as a command. You can also use service [service] start, stop & restart. In other linux systems substitute service with /etc/init.d/, for example /etc/init.d/sshd status or start etc.

To make a service start automatically at boot time, in Fedora Core, type chkconfig [service] on (or off) so to make the ssh daemon start automatically, type chkconfig sshd on. On Debian, it's update-rc.d sshd defaults and on Gentoo, it's rc-update add sshd default. Very consistent across all systems as you can see. If you feel confused feel free to use the man command. To test, reboot and see.

Now, you need to configure your ssh daemon to be nice and “tight”. Sshd gets its settings from /etc/ssh/sshd_config. The best way I can help you out here is to show you. I changed some things like IP addresses, of course. Remember, lines that start with # are comments. That means that when the daemon reads the configuration file, it will skip over these lines. I have inserted my own comments as well, all properly commented out, so you should be able to copy and paste to heart's content. Here goes:

--- start of file ---

Protocol 2 # this means only Protocol 2 – protocol 1 is insecure

SyslogFacility AUTHPRIV

# Authentication:

LoginGraceTime 20		# 20 seconds to log on otherwise you get booted out
PermitRootLogin no	# don't let root log on 
MaxAuthTries 1		# no forgiveness for a bot right here

PermitEmptyPasswords no
PasswordAuthentication yes

ChallengeResponseAuthentication no

GSSAPIAuthentication no
GSSAPICleanupCredentials no

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
AcceptEnv LC_IDENTIFICATION LC_ALL
AllowTcpForwarding yes
X11Forwarding yes		# not necessary, you can say no, but it's useful s/times
PrintMotd yes		# this prints out a nice nasty banner, defined below
TCPKeepAlive yes

# override default of no subsystems
Subsystem	sftp	/usr/libexec/openssh/sftp-server

#which users can log in
AllowUsers	backupop admlocal # further restrict, allowing only specific users

Protocol 2 # this means only Protocol 2 – protocol 1 is insecure

SyslogFacility AUTHPRIV

# Authentication:

LoginGraceTime 20		# 20 seconds to log on otherwise you get booted out
PermitRootLogin no	# don't let root log on 
MaxAuthTries 1		# no forgiveness for a bot right here

PermitEmptyPasswords no
PasswordAuthentication yes

ChallengeResponseAuthentication no

GSSAPIAuthentication no
GSSAPICleanupCredentials no

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
AcceptEnv LC_IDENTIFICATION LC_ALL
AllowTcpForwarding yes
X11Forwarding yes		# not necessary, you can say no, but it's useful s/times
PrintMotd yes		# this prints out a nice nasty banner, defined below
TCPKeepAlive yes

# override default of no subsystems
Subsystem	sftp	/usr/libexec/openssh/sftp-server

#which users can log in
AllowUsers	backupop admlocal # further restrict, allowing only specific users

#login warning banner for security
banner		/etc/ssh/sshd_banner
# this is the message everyone will see when they log in, so say something really 
# mean and threatening.

--- end of file ---

Don't be scared if you notice that your configuration file is ten times as long - I just included the commands not commented out in mine. Take your time, read the man page (man ssh) and craft something you feel proud of.

So now, run /etc/init.d/sshd restart & try logging on from another linux PC on the subnet. Note that you should NOT have root login enabled for any reason. If you need root privileges, log in as a normal user and run su. su will prompt for the root password and voila'. If the root account is disabled, use the sudo command (man sudo anyone?).

Now, before you get too excited, open up port 22 on your Linux server's firewall. In Fedora Core, I use

system-config-firewall or system-config-firewall-tui (the last is for the terminal) and away we go. On the other distros, find a GUI. Good luck.

ACCESSING YOUR SERVER FROM THE INTERNET

All internet access in your company ultimately goes through your router (in addition to whatever else - I have a web proxy on my IPCop). Your router usually has a fixed IP address with the ISP. To find out, go to your router's management interface with a web browser from a machine in your local network (in the address bar type http://[router ip address]). It will be in the summary page.

I do hope you have looked at this before. If not, the login is usually admin and the two most common passwords are admin and 1243. Get familiar with the various menus and don't forget to change the password. You may want to download the manual for the particular router you are using and study that as well.

If you don't have a fixed IP, you should be able to address your router with DynamicDNS – but I have never tried so go talk to your Scottish friend google.

From the outside, you will talk to your router who will then forward the connection to your server, inside your subnet. Now, if you just up and enable port 22 on your router, a slew of bots and attacks will make you wish you never had. So pick a port which is way up there, something higher that 35000, and enable that. Have the router listen only on this port, and then pass this to your Linux server on port 22, as if it was a normal connection. On my system, my router forwards this higher-level port on to the IPCop firewall, which then passes it on to port 22 on my server.

The first thing to test is if you can SSH into your linux server. So from your Linux laptop outside your network, try ssh -p [port-router-is-listening-on] -l [user name on server] [router fixed ip address]. If you get a password prompt and it lets you in, you are good to go.

Now, we need to configure some connection options that will make it easier to use ssh on a daily basis. On your Laptop, create a file called ~/.ssh/config. In this file, you can create a connection name and set all of the parameters for that connection, for example, on mine:

--- start of file ---

Host linserv # Arbitrary name for the connection

HostName [router fixed IP address]

Port [port-router-is-listening-on]

Compression yes

User [user name on server]

ForwardX11 yes # not necessary, you can skip out on this one

--- end of file ---

Make sure you include Compression – it will come in very handy when you run VNC over this SSH connection.

So you should now be able to go into a terminal and type ssh linserv (or whatever the value of Host is for you) and get a password prompt. Much better.

ADMINISTER WINDOWS VNC DESKTOPS REMOTELY

What does this have to do with the VNC desktops you set up earlier, you ask? Ah-HA! You see, opening the VNC port (5900) up to the internet is really suicidal, and I hope you never do it. Your desktops have it open, but you can only get to them from inside your network. So what to do? You access VNC on windows computers via the SSH connection you established to your linux server.

I am assuming you have TightVNC installed – most people do. Run vncviewer -quality 0 -compresslevel 9 -bgr233 -via [linserv] [windows-pc]:0

The quality, compresslevel and bgr233 are settings that I use to crunch the signal down as small as possible so I get close to realtime treatment even over slow connections. The via option tells vncviewer to use ssh and the linserv argument is simply the name I gave the connection by setting the Host value in ~/.ssh/config above.

The last argument is the hostname of the windows PC. :0 means screen 0 (windows VNC will be found on this screen, always). Keep in mind that with the -via option, vncviewer resolves the hostname you give it from the point of view of the linux server you connect to with ssh. You can also use an internal IP address, as long as the linux server on the internal network is able to access it.

CONNECT TO THE LINUX SERVER ITSELF WITH VNC

You need to install VNC. On Fedora Core, it's yum install vnc-server

Then, type vncserver not as root but as the user you will be accessing as. The first time you run it, it will generate some files and ask you for the password to request when vncviewer establishes as connection. As soon as it does so do vncserver -kill :1 (vncserver will have told you what monitor it started up as – it's usually :1 but if it's different, stop that one).

Now edit ~/.vnc/xstartup Comment out (with #) the line twm & and insert the line gnome-session & or startkde & instead.

Now run vncserver It will tell you what screen it started up (usually :1). Good. Run vncviewer like so: vncviewer -quality 0 -compresslevel 9 -bgr233 -via [linserv] localhost:1.

You should not run into firewall problems. You are connecting to localhost since vncviewer is going through ssh all the way there already.

If you want to, you can set vncserver to start automatically. Personally, mine is always off until I connect to my server with SSH & run vncserver to start up my VNC server. After logging in as above, I run vncserver -kill :1 to terminate the service on my server and thus be that much more secure. I of course wrote a script for that, but we'll save it for another time.

Good luck!