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 and 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.
sudo http_proxy= apt-get install openssh-server openssh-blacklist openssh-blacklist-extra
Initially when I did this, I installed just the openssh-server package and noticed these five lines that were output during the installation.
Setting up openssh-server (1:5.9p1-5ubuntu1) ... Creating SSH2 RSA key; this may take some time ... Creating SSH2 DSA key; this may take some time ... Creating SSH2 ECDSA key; this may take some time ... ssh start/running, process 13031
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.
$ ps -AHF | grep ssh
jrcharney 2132 2087 0 1020 24 0 Dec14 ? 00:00:01 /usr/bin/ssh-agent /usr/bin/dbus-launch
--exit-with-session gnome-session --session=gnome
jrcharney 16611 17249 0 1097 836 0 14:53 pts/4 00:00:00 grep --color=auto ssh
jrcharney 13536 13310 0 1580 2504 0 12:58 pts/5 00:00:08 ssh [REDACTED]
jrcharney 16462 16228 0 1257 1568 0 14:45 pts/6 00:00:00 man ssh
root 13031 1 0 1671 2432 1 12:51 ? 00:00:00 /usr/sbin/sshd -D
The process list says there is an SSH Daemon (sshd) running, but is it active?
$ netstat -an | less Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp6 0 0 :::5900 :::* LISTEN tcp6 0 0 :::80 :::* LISTEN tcp6 0 0 :::22 :::* LISTEN
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.
$ ssh jrcharney@192.168.x.y ssh: exited: Error connecting No route to host
ipconfigSo 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.
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.factory-defaults sudo chmod a-w /etc/ssh/sshd_config.factory-defaults sudo vim /etc/ssh/sshd_config
- 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
AllowTcpForwarding yesandX11Forwarding 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 usingDenyUsers loginName1 logninName2. - Log all logins! To keep the baddies out, track who attemps to log in. Change
LogLevelfromINFOtoVERBOSE. 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.nettoBanner /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.
$ figlet jrcharney _ _ (_)_ __ ___| |__ __ _ _ __ _ __ ___ _ _ | | '__/ __| '_ \ / _` | '__| '_ \ / _ \ | | | | | | | (__| | | | (_| | | | | | | __/ |_| | _/ |_| \___|_| |_|\__,_|_| |_| |_|\___|\__, | |__/ |___/ sudo figlet jrcharney >> /etc/issues.net
figlet. We should have more fun with this in the future! See if we can add some color.OK, with our config file set up (and possibly banner too), let's save it (:w) and restart sshd.
$ sudo restart ssh $ sudo restart ssh [sudo] password for jrcharney: ssh start/running, process 19133
OK, let's try this again...1...2..3...
$ ssh jrcharney@192.168.x.y ssh: exited: Error connecting No route to host
Nothing? What if we tried adding a port number to the end.
$ ssh jrcharney@192.168.x.y:22 ssh: exited: Error resolving '192.168.x.y:22' port '22'. No address associated with hostname
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.
