December 16, 2012
One Giant Leap Forward (Part 2)
Welcome back to our short series on remote computing. It took me a while to get back to this post as there were a few things more required that I needed before I could elaborate on how to establish a remote connection.
For years, I've accessed my webserver that hosts this website and its predicessors using Secure Shell or SSH. Being a Linux geek, and having downloaded software for many years prior to using Linux using FTP, I wanted to immerse myself in the experience of being a computer programmer. To train myself not to focus on using Graphical User Interfaces (GUIs) but the Command-Line Interfaces (CLIs) that traditionally are the signature methods of a computer programmer, web developer, database adminstrator, or data entry clerk. To free myself of the mouse and the touch screen and keep both hands on the keyboard where my hands belong.
Imagine you are a line cook at a restaurant who makes an exquist meal. One day you have a customer come in demanding the chef cook this mean in front of him.
Because you have to make something outside of your post in the kitchen (CLI) and have to make it in the dining room (GUI) where the customer wants you to cook their food (demonstrate a program or writing a program) in front of them. But the tools you make to be that great chef are at the kitchen's grill, not at the dining room grill where the sushi chef works most of the time. In this case, you have to use his grill to get to your grill. (Hopefully this metaphor is clear enough to understand.)
Because you can not leave the dining room grill to get the items from your grill without the rist of a customer trying to reach over and take something that doesn't belong to them (consider this the metaphor for just using VNC with an insecure connection), you need to use a couple of sous chefs (an SSH client and an SSH server) to connect with your commis to handle message off to the souses including the information to the recipie that you use to make that meal without the customer (who could be a spy from a rival restaurant) gaining access to it.
To further make this metaphorical example sound more relevant to a computer setting, let say that the two souses are divided by a wall with a small window in it (firewall) such that the souses can transfer items (encrypted packets) beetween you and your commis. Without the souses items that should be kept private might be easy to see by unauthorized eyes. Remeber, a direct VNC connection is not encrypted and thusly not secure.
Now there are products on the market that have been advertised quite promenantly the past few years like the ones that are advertised by Citrix (i.e. GoToMyPC and GoToMeeting). Today's post (and last weeks) uses non-prorprietary software. This also means, wel will not be using any method that uses the Remote Desktop Protocol (RDP) as that is a proprietary product as well unlike the Remote Framebuffer Protocol (RFB) which was designed to work with VNC. As much as I have stated that VNC does not come with its own encryption, using VNC through an SSH tunnel using port forwarding is more secure than using straight RDP.
So why didn't I show using the SSH Tunnel for VNC in the previous post? Well for starter, I hadn't really need to use this stuff. Secondly, my forte is in programming not IT and network communications, although I am learning as I go along, in fact there may be more posts like this in the future. And lastly, Compy (my netbook) is on its last legs. There is an urgency to rebuild my desktop computer but not the funding meaning there is an urgen push to move toward using my Touchpad as the interface for computer work. In fact, I wish I had learn about his back when the desktop was operational. Compy probably would have lasted much longer.
So until we can afford to fix EVERYTHING, these efforts are critical toward keeping myself in the business of programming. A chef can't work without a stove and a computer programmer can't work without a computer.
Right, now down to the meat and potatoes of this post, the how to part.
The computer that you will want to connect two will need to have Vino installed. Last post shows you how. But for the security part, you will need to install the OpenSSH server package,
openssh-server, as well as a couple of other things that look helpful like
openssh-blacklist-extra. If you are wondering "Hey, I can access SSH using the
ssh command, why do I need this?" It's because
ssh is the client program which is part of the
openssh-client package you probably installed before. The server package now installs the daemon, that is the background process much like we saw when we enabled Vino to work. I'll post some figures later in this article.
Keep in mind, that these instructions are designed for Debian-based Linux distros like Ubuntu, Linux Mint, or Debian. YMMV.
Initially when I did this, I installed just the
openssh-server package and noticed these five lines that were output during the installation.
There is a good chance that this installation will not be completely set up until you restart the machine, but for now here's what I get when I call up the process list of for SSH.
The process list says there is an SSH Daemon (
sshd) running, but is it active?
Apparently so. As usually, use
ipconfig like in the previous post to see where your IP Address is.
OK, we have our machine set up. As I stated previously, the computer I want to connect to will be my tablet. And as I stated previously, there are two apps that I recommend to use on Android for SSH. One is Connectbot and the other is AirTerm. I want to use AirTerm first so that I can demonstrate what the output would look like if I was using another computer.
AirTerm uses Dropbear as its SSH client and the output should be similar to that if I wanted to use another computer with OpenSSH to access my computer. ConnectBot seems to do this with a GUI set up, which we already discussed how I feel about using GUIs when programming is involved. On the other hand, ConnectBot does save your connection settings. For now, we'll use Dropbear SSH in AirTerm to understand how this works then we can fill out the form in ConnectBot to automatically do that for us.
So here's what happens when I try to access Compy through my tablet via AirTerm/Dropbear.
So what happend? It wouldn't even ask for a password or ask us to establish a RSA passkey so that the devices get to know each other. Why can we get in? Probably because we didn't configure the SSH Server (which hence force we'll call the server 'sshd' and the client 'ssh').
Back at Compy, we need to got to
/etc/ssh/sshd_config to get sshd set up. this page on the Community Ubuntu Documentation website seems to go over the set up, but I will make the following suggestion in the next figure.
Firstly, make a backup copy of the
sshd_config file then use
vim to edit it.
- Keep password authentication enabled. Leave the
#PasswordAuthentication yesline as is and use a VERY STRONG password that uses a long password that use letters, numbers, and other characters. Keep in mind, when we use ConnectBot later, remembering the password will be no problem.
- Keep port forwarding enabled. That is the entire point of this blog post. So leave the lines that say
X11Forwarding yesas they are. If they aren't like that, set them like that. Hopefully you remembered to set up a password when setting up VNC last time. If neither lines exist, add the ones that done to the end of the file.
- Add which users should be allowed to access the computer at the bottom of the file. At the end of the file include a (space separated) list of people allowed to access your computer with
AllowUsers loginNameat the bottom. You can deny users as well using
DenyUsers loginName1 logninName2.
- Log all logins! To keep the baddies out, track who attemps to log in. Change
VERBOSE. Check the
/var/log/auth.logfile regularly. If anything doesn't look right, add them to the blacklist. (I'll probably go over how to use that in the future.)
- Add a banner...because its fun! Sure that page will say "Add it for security", but you just want to play with figlet like they do on the IRC servers. At any rate change
Banner /etc/issue.netand make a copy of
/etc/issue.net, twice. Once for the default, and secondly to back up your thing incase it gets replaced upon a system upgrade.
OK, with our config file set up (and possibly banner too), let's save it (:w) and restart
OK, let's try this again...1...2..3...
Nothing? What if we tried adding a port number to the end.
We could check our iptables to see if that helps. Remember the firewall.
Something tells me I should work on a part 3 of this article. Yeah. Next time we talk about firewalls and iptables.