Mike Levin SEO

Future-proof your technology-skills with Linux, Python, vim & git... and me!

OpenSSH and QEMU Network Address Translation (NAT)

by Mike Levin SEO & Datamaster, 08/24/2010

I sort of lost my way that this part of the ShankServer security tutorial was all about OpenSSH. Let’s do some quick catching up. I will be re-installing OpenSSH, but I want to emphasize the point of a server’s open footprint of open ports for hackers to probe and profile. You can see the entire list of open ports by typing:

netstat -tulpn

And now we install OpenSSH. If you already have followed my earlier instructions, you don’t have to do this.

apt-get install openssh-server Y

…and we run netstat -tulpn again after installing OpenSSH, and we can see that we went from no ports listening on any protocol to port 22 listening using tcp and tcp6 protocol. It’s a much less secure server now, but without any NAT set up, it’s still can’t be reached from the outside.

This is where I was when I lost my momentum last time around. Creating a NAT entry for QEMU is as simple as adding a parameter to the command that launches QEMU. Remember, we set up a .bat file in:


…to launch qemu under Windows and set up a bash script for Mac OS X in:


Unfortunately, this means that we have to make our parameter updates in two locations, but its really no big deal. If you made it this far, then it will be no problem to make the edits.

Make this edit to qemu.bat:

qemu -hda ../Guest/Debian.qvm/harddrive.raw -redir tcp:2222::22

…and make this edit to Debian.sh:

#!/bin/bash cd “${0%/*}” ./i386-softmmu -hda ../Resources/Guest/Debian.qvm/harddrive.raw -redir tcp:2222::22

Simple as that. Now, there is a network address translation to let SSH traffic that comes in through port 2222 in to your QEMU virtual server, routing it in through port 22: putty localhost port 2222

But as you can see, because we didn’t deal with SSH keys yet, we’re getting a security warning: potential security breach

You may not get this message, but a much more benign sounding one: “The server’s host key is not cached in the registry”. The server’s host key is not actually cached in the registry–only it’s fingerprint. This is to know that you’re looking at the same server this time as you were looking at last time, as a precaution. The reason I’m getting a different message than you are likely to be getting is because I have connected to localhost over port 2222 before using PuTTY. It remembers it, because PuTTY caches the fingerprint in the registry. It’s okay to click “Yes”, because you do indeed know that it is your server.

It is worth pointing out here that SSH provides a number of authentication methods, such as public/private key and keyboard interactive. Public/private key is probably more secure, and even eliminates the need to type in a login/password (it just instantly connects!). But you would have to generate a public/private key on the client (the machine running PuTTY) and somehow get the public key over to the virtual server and write it into a particular ssh file of authorized computers. Since this isn’t set up ahead of time, hitting Yes is going to roll over to the interactive username/password method. So, simply use the login credentials you set up for the “inmate” user: successful ssh login

Notice that inmate is logged in to ShankServer without admin rights. You can tell from the dollar-sign ($) that’s at the end of the prompt, rather than the hash-symbol (#). But since we set up sudo, all you have to do is type:

sudo su

…and provide your password again, and you have promoted yourself to admin rights: sudo su

Yeah, yeah, I can hear all the admins looking at this cursing me for teaching you to use the “sudo su” command to promote your shell session to persistent superuser privileges instead of on a command-by-command basis. And they’re right. If this were not a QEMU virtual Linux pendrive, walking away from your PC at this point could be devastating, and it is much better to promote yourself to admin on a command-by-command basis. Sudo can be used before any command. So say for example, you didn’t “sudo su” and wanted to edit your network configuration and actually wanted to be able to save it when you were done (I first typed exit to get out of superuser login):

sudo vi /etc/network/interfaces sudo vi etc network interfaces

And this is the end of a very long journey. Your QEMU Linux pendrive is now a super-awesome magic-trick and blank slate for infinite potential projects. You don’t have a lick more software than you need running, but you have precisely what you need running to “get at” the machine, if you didn’t have a monitor attached for access to the built-in console.

Get it? The PuTTY window is a terminal, while the QEMU window is an emulated native console–as if real hardware. Even while we’re running PuTTY, the default console is there. In this tutorial right now, they’re both actually on my screen: linux console vs terminal

…but acquiring this skill to log in without access to a native console is all-important, because that is the predominant world of servers, and the skill we’re going to need for the next state of this website… trading up from a pendrive to a Plug Computer that doesn’t have a monitor port!

And finally, you can shutdown your QEMU session from an SSH login just as you would from a native console, by typing:

sudo shutdown -h now sudo shutdown h now

The console will disappear automatically, and the PuTTY window will become inactive and need to be closed after you click “OK”.