Weekly column is up, enjoy. Something a little different this week. <G> TTFN...

Join Project Conestoga

Monday, January 8 - SSH

This started out as a discussion about the wierd things in the new version of SSH, then morphed into a quickie tutorial. If you already know how to install and use ssh, click here.

SSH (Secure Shell) is a critical utility for me; I have several Unix servers at work, and more at home, and I have to be able to administrate all of them - preferably from one place. (Sysadmins are lazy creatures, you see... <G>) "In the old days" you used telnet to do that - it allowed you to send commands over a network connection to be executed on another machine. Telnet still has some utility, mostly for debugging network connections, but it has one critical flaw - everything is sent in plain text. Which means that anyone who happens to be on the same network (in the case of hte Internet, world+dog) can eavesdrop on the communication, collecting usernames, passwords, and anything else you send across the connection. Like most administrators, I don't even run a telnet server on any of my machines anymore.

SSH fixes that. In some ways, it's just like Telnet; it sends commands over the network to be executed on the remote machine. Unlike telnet, though, SSH is encrypted, so it's nearly impossible to eavesdrop on its communications. SSH also includes the ability to transfer files from machine to machine (via sftp or scp) which Telnet does not. There are a few things to be aware of - like how to identify the machine you're connecting to, in order to be certain it's the correct machine - but overall, it's a robust, secure replacement for Telnet.

There are a couple of different SSH servers; the two most common are SSH, from SSH Communications Security, and OpenSSH, an Open-Source version. I prefer the commercial SSH; it's free for non-commercial uses, and it seems to be more stable and more robust than OpenSSH. I've had problems with OpenSSH refusing to connect to some servers, but the commercial SSH I rarely have problems with.

The next important thing to remember is that there are two versions of the SSH protocol; Version 1 and Version 2. Version 2 is the standard, with stronger encryption and better authentication methods, but SSH1 is still in use on a lot of servers, particularly servers running OpenSSH servers. Fortunately, both OpenSSH2 and SSH2 are backwards-compatable.

Installing SSH is not difficult. If you're running Windows, there's a new server from SSH.com; the link is to the non-commercial version. I've not used it yet, but I'm told it works fairly well. Of course, you can also install client software; I use the official SSH Windows Client (also the non-commercial version) on my Windows machines. It's very easy to install, and I've never had a single problem using the default values.

Installing SSH on Unix/Linux is a little more complex, but still not too bad. With OpenSSH, it's easiest to install using a package manager like RPM or APT-GET; some distributions like Mandrake and Debian include OpenSSH by default. If not, I use RPMFIND to track down the latest rpm packages, and install from there. If you're not into using package managers, OpenSSH is available as a source tarball, and it compiles the same as SSH does.

For SSH, on the other hand, it's better to compile it. They make rpm packages available here, but I've had some problems with those packages in the past. Unless you can't compile it yourself for whatever reason, I'd avoid those packages.

Here's how to compile either OpenSSH or SSH on a Mandrake Linux system; the same steps work on Solaris and HP-UX, so I'm pretty sure they'll work on any Unix system:

1. Obtain the source tarball. The latest version of SSH is here and OpenSSH is here. (For other OpenSSH mirrors, look here.)

2. Unpack the tarball with the command "tar -xvzf ssh-2.4.0.tar.gz" or "tar -xvzf openssh-2.3.0.tgz".

3. cd into the new subdirectory with "cd ssh-2.4.0" for SSH and "cd ssh" for OpenSSH.

4. Both packages are fairly good at self-configuring; simply run "./configure". This step will take a few minutes as the installation script checks your system configuration.

5. Once the configuration is completed, become root (su, hit enter, type the root password) and just type "make". This step will also take a few minutes - how long depends on the speed of your computer.

6. If the make completes without error - and it should, I've not had a problem with either OpenSSH or SSH on several platforms - type "make install", hit enter, and you're done - for OpenSSH.

7. If A) You're running SSH from ssh.com, B) you're installing on Mandrake or RedHat Linux, and C) you want to run the SSH server as well as the client (I usually do, but that doesn't necessarily mean you should) then there's one more step. In the same directory that SSH created (ssh-2.4.0) there is a file, sshd2.start. That file is the daemon-init script for the SSH server. What that means is that you have to copy it into the right place on your system and tell RedHat or Mandrake that it's there. (The same script should work on SuSe, but I haven't tested that.)

1. copy the file to the same location as the other init scripts with the command "cp sshd2.start /etc/rc.d/init.d/sshd"

That will copy the file to the folder /etc/rc.d/init.d/ and rename it "sshd"

2. type "chkconfig sshd on" to let RadHat or Mandrake know you want that daemon (like a Windows service, more or less) started whenever the system boots

3. Either reboot, or manually start the SSH server by typing "/etc/rc.d/init.d/sshd start"

That's it, ssh is now up and running. To use it, as yourself (not root) type "ssh -l <user_on_remote_system> <remote_system_name>". After a few seconds, the server will display some information about the server you're connecting to and ask if you want to save the key to the disk; say Yes. The system will then prompt for your password; that's the user password for the user on the remote machine. for example, to connect to my home machine from work, I type "ssh -l matt rearviewmirror.org", then the password. After the first time connecting, the system won't bother asking if I want to save the remote system's keyfile, it'll skip straight to asking for the password. Unless the keyfile changes. IF IT CHANGES DO NOT CONNECT TO THE SYSTEM unless you know why it changed. There are legitimate reasons for it to change - the system was reinstalled, SSH was deleted and reinstalled, and so on. But it can also be a sign that someone is using what's known as a "man-in-the-middle attack" to try and eavesdrop on the communication.

Copying files from one ssh-enabled machine to another is also easy; the basic format is "scp <options> <user@hosta:path/file> <user@hostb:path/file>". That's a little confusing to look at, so let's break it down.

When I finish an update to the web site, I copy it from my workstation to the web server using scp. This week's file is named 10801.html, and it's in the /home/matt/Documents/rvm/musings/2001/ folder on my workstation. I want to copy the file to the /home/http/rvm/musings/2001/ folder on the web server. I could use this command:

scp /home/matt/Documents/rvm/musings/2001/10801.html matt@rearviewmirror.org:/home/http/rvm/musings/2001/

But that's pretty long, don't you think? I can shorten it by shortening the path to the file on my workstation; for example, I'm probably already in "/home/matt/". So now the command looks like this:

scp Documents/rvm/musings/2001/10801.html matt@rearviewmirror.org:/home/http/rvm/musings/2001/

Because I cheat (I have a script on the server to watch for changed files in my home directory and copy them to the web folder) I can shorten the path on the other end, too:

scp Documents/rvm/musings/2001/10801.html matt@rearviewmirror.org:musings/2001/

Now, notice I don't use a "<user@host>" there. That's because the file I want to copy - the source file - is on the machine I'm using. But it doesn't have to be. Maybe I made a post last night, and now I want to copy the changed file to this workstation before I start making a new post. No problem, just rever the order:

scp matt@rearviewmirror.org:musings/2001/10801.html Documents/rvm/musings/2001/

I can even copy a file from one ssh enabled machine to another without being logged on to either machine:

scp matt@rearviewmirror.org:musings/2001/10801.html matt@thoth.rearviewmirror.org:Documents/rvm/musings/2001/

But suppose I want to copy more than one file. Use the -r, recursive, option, and copy a whole directory tree. Suppose I'm setting up a new workstation, and I need a local copy of the whle site:

scp -r matt@rearviewmirror.org:* Documents/rvm/

ssh -l matt -p 2200 foo.bar.com

Using scp, it used to be in the format "scp user@host#port:path/file", and it still is, with OpenSSH, but SSH (to my annoyance) changed it to -P when using scp, so it's now "scp -P port user@host:path/file". It took several frustrating minutes to figure that one out, since there's not mention of the change except deep in the documentation.

Which brings us to my original topic for the day. (Whew!) SSH 2.4.0 makes several noticable changes. Some of them are pretty minor, just interface things; the SCP progress bars are formatted differently, for example, and several of the prompts have had their wording changed. Most of those changes are good, or at least are no worse than the original. However, ssh has changed some of the options (I can't be certain, but I don't think the scp port change is the only one) and that isn't so good. Before, OpenSSH and SSH were completely compatable; if you new how to use one, you knew how to use the other. There were cosmetic differences, but nothing that really mattered changed from one to the other. Now they're changing that; OpenSSH users will have one set of commands, SSH users another. I don't know if it's an attempt to protect their user base from OpenSSH, an attempt to make scp a little less confusing (possible) or simple insanity, but they've done it. The question now is, what will OpenSSH do? Will their new version also reflect these changes, or will they keep their software the way it is? Andif they keep it the way it is, does that mean one side or the other will disappear?

I dunno. What do you think? <G>

Some news & thoughts on Project Conestoga tonight or tomorrow; I have some emails to wade through, and some thoughts to firm up before I post them. Until then, see you later...

Tuesday, January 9 - News of the Day

Hmmm... let's see... what happened today that's noteworthy... started the final move process for the last floor of the office, which involves a bit of yelling, a bit of ranting, and some pleading - but mostly the yelling and ranting. <G> FortyTwo is having more serious problems, so I think the site is going to have to go back on Hydras (graciously hosted by the employed Tom Syroid) until we finish moving to Seattle and I get everything resettled...

Oh. Yeah. Employed. Me too. <G>

As of five minutes ago, I returned a signed offer letter from Meridian Technology Group, a contracting firm in Seattle (and Portland, and other places, I expect) accepting a six month contract at AT&T Wireless. I don't have all the gory details on the position, but it's a little NT, a little Unix, a little telephony (the wireless kind) and a lot of making brand-spanking-new engineering solutions work the way they should, rather than how the engineers intended. <G>. So the Great Job Hunt of 2000 is over, only slightly after 2000 itself was over. Incidently, Keri has not only held up very well through the uncertainty of the job hunt, and not only not whined too much about not being in Seattle (I'm gona get it for that one) but she also predicted, to the day, when the job hunt would be over. A little over a week ago. Believe it or not, that's pretty impressive; I expected it to either be over last week, or nearer to the end of the month. But hey, I'll take it. <G>

I was playing with the office digital camera this morning, adjusting different settings and examing the capabilities, so there are a few pictures scattered around. Here are a few of the interesting ones of my work area...

(Note to Bob and the other "no clean floor" zealots: Siebel's clean desk policy is enforced. But not all that well, in my case...)

First, a normal Siebel Systems Inc. cubical, intended for one person (despite the second chair) for comparison. Yes, this is an occupied cube, although the poor sap has fled, probably from the sensory deprivation. (The thumbnail links to the full image, which is roughly 46k)

I know, I know. Pretty neat compared to a real pro like Tom or Bob. But just remember - that's with Siebel's (futile) attempts to get me into compliance with the clean desk policy. <G>

Oh, just for a quick rundown... the laptop on the left side of the image is Scooter, the IBM ThinkPad T20, running Windows 2000 Professional; the white center/main monitor is connected to Kermit, the large Compaq DeskPro at the bottom of the stack topped by the black monitor, which is connected to Igor, the IBM Personal Computer 300PL on the same stack - just below the monitor. The two Compaq DeskPros to the right of that stack are empty shells, stripped of parts for other machines. The switch sitting on top of them is a 3Com SuperStackII 24 port switch, used for temporary LANs in the QA department. The box on top of the DeskPro cases is my personal Mandrake Linux 7.2 Deluxe boxed edition, which is what's running on Igor and Kermit. And the small picture-framish item there is a sand-painting-sculpture thing (the sand is suspended in oil, so it constantly changes) my boss gave me for Christmas.