Mike Levin SEO

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

How To Install SSH Server for Remote Login

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

We finished building our bare-bones virtual Linux pendrive. It’s double-clickable on Mac or PC, easy to carry around, and a solid foundation to gain Linux Server experience and prepare to make the leap off onto real hardware. Making that leap will be easy, but first, we have to interact with our virtual server a little differently–more like a hardware server, so when we get to real hardware, things won’t be too different.

I’ve also closed the chapter on the WordPress category, “Learning Linux” and have moved onto one I call “Scrutinizing Security” of which this is the first page. As this Linux tutorial starts to gain popularity, I expect it to catch heat from the textbook SlashDot reader for glossing over security issues, and I plan to nip it into the bud out of the starting-gate. Newbies can be meticulous about security from the get-go, and now that we’re ready to connect to the virtual computer in a different way, it’s the perfect time to dedicate a series of lessons to the cause.

It’s rare that you would ever type directly into a server’s main console (keyboard & monitor) like we’re simulating here with QEMU. Rather, you would access it remotely. In fact, most servers are run without keyboards or monitors attached at all. They are referred to as “headless” and are most often mounted in server cabinet racks behind locked doors. Our Linux keychain project here is designed to let you begin to cross over into that world (and come back safely). Instead of turning you into a server closet monkey, we will turn you into a micro-server wielding 800 pound gorilla who can make thousands of carbon copies of him/herself in the cloud–a stronger position to be in.

On this post, we’re going to learn how to treat our virtual server as if it were headless, and do our first apt-get software installation in order to enable remote login. Remember, apt-get is the command we used to update our software repository. The same command is used to install software. For the impatient among you, just scroll to the bottom for the command. For those who want to escalate their stature through knowledge, read on.

When server maintenance needs to be done in-person on a headless server, there are a few options. One is attaching a keyboard and monitor, but that’s what we’re already simulating here with QEMU when you lose your pointer. The hardware-based ShankServers I’ll be teaching you how to build will be headless, without even ports for a mouse and keyboard. So, will have to learn other ways to connect.

On real hardware, you can also connect by plugging a terminal device into the serial port, for what’s called direct serial access. Back in the days when powerful computers were large, expensive and uncommon, cheaper “dumb terminals”, were the way to connect. They worked similar to an even earlier type of device called Tele-Typewriters that let you send typing over phone-lines as an alternative to expensive long-distance international calls. Because computer terminals looked and acted so much like teletypewriters, the abbreviation TTY stuck for this whole category of device and replacement software.

Today, terminal software running on regular computers has taken the place of dumb terminals. HyperTerm found on nearly every copy of Windows up until Vista is an example of such terminal software. Direct serial connections are still done regularly on equipment that shouldn’t have monitor & keyboard ports, like routers, switches, network-attached storage (NAS), and smart power supplies. These connections are very private and secure because there is no real network involved–just the direct flow of bits between two machines. In particular, there is no “Internet” on that direct serial communication channel. The SheevaPlug, one of the good ShankServer pieces of hardware we’ll be discussing later, comes with its own serial cable for this purpose, which we may use at some point, so keep that in mind.

But these days by far, the most popular way to connect to servers is over TCP/IP, which is the same popular networking protocol of the Internet. In fact, it’s not uncommon to be able to reach a server to perform maintenance directly over the Internet, although this poses security risks.

The first type of software to allow this was called telnet, which worked just like dumb computer terminal emulators, working straight over TCP/IP with no special encryption. However, if you’re doing server maintenance with telnet, you’re giving your logins and passwords to anyone snooping along the route. So encryption was added, and old telnet software faded into obsolescence, replaced on one side by Web browsers, and on the other side by Secure Shells (or SSH).

The World Wide Web basically happened, and the chasm between those who were technical, and those who were just Web surfing consumers grew wider. Who really even discusses or knows about SSH software? This is surprising, because it’s the primary way to interact with non-Windows servers these days, and a necessary part of becoming vendor-independently technical. Oddly, Windows doesn’t even ship with Secure Shell software, but it does ship with obsolete telnet. Up until Vista, telenet was part of default Windows, and is now still even an option you can install from the CD-ROM through Add/Remove Windows Components. But Secure Shell is not. On the flip-side, Mac’s has the SSH command built into its Terminal, as any good Unix would. Therefore, it’s not surprising that even though Apple has such a reputation for vendor-lock-in, it nonetheless attracts the vendor-independent crowd thanks to the industry-standard POSIX-compliant version of Unix that it’s built on.

So it’s time to connect to our virtual machine through SSH. We only lack two things:

  1. SSH client software on the PC
  2. SSH server software on your virtual machine

Because you see, the capability to connect via the Internet to a server isn’t part of most default Linux/Unix setups. It’s a deliberate choice that the person who set up the server has to make. Special software needs to be running that knows to listen to communicate attempts over it’s networking connection. Our installation of bare-bones Debian Linux didn’t include it, so it’s the ideal software to install first. Thankfully, there’s a defacto standard SSH server in the Debian Repository called OpenSSH. And this has been a very long post leading up to the simple instruction to type:

(But before you do, make sure you make a copy of harddrive.raw, because this is the last time it will be in that “pristine” debootstrapped state.)

apt-get install openssh-server

You’ll see a bunch of things scroll past you, and you’ll have to answer “Y” to finish.

After answering yes, you’ll have a little bit to wait–maybe 5 minutes, but when it’s done, you’ll have an SSH server running and won’t ever need to login from the QEMU main console that gobbles up your pointer and doesn’t allow copy-and-paste. Instead, you’ll use tools like PuTTY on the PC or the built-in terminal on the Mac.

We will be moving on in subsequent posts to discuss many issues, like:

  1. Trying to log into our virtual machine through SSH from the host machine, realizing we can’t, and a discussion of why security is THAT tight.
  2. Tidying these security issues, like how to disable and lock the root account.
  3. Before disabling the root account, how to make a new user, and allow it to be able to temporarily acquire root privileges when needed (making it a sudoer), using the sudo command.
  4. Discussing what the SSH2 RSA key and SSH2 DSA keys are, how they’re going to be used for the connection whether you like it or not, and how to be deliberate about it.
  5. And finally, changing the parameters that QEMU uses to launch the virtual machine (on both the Mac and PC side) so that we can SSH into it from the host machine, or other machines on the LAN
  6. A discussion of how to leave the VM running so that you can log onto it from the Internet at large, getting through your WiFi router, etc.
  7. A discussion of the topic of surface area reduction (greatly already done, because we debootstrapped) and Linux system hardening.