Cory Collier

I used to always refer to a different site when I wanted to remember how to setup a machine to use SSH without a password. That site (I don’t recall what it is) isn’t around anymore. So, I guess I have to post the tutorial here.

SSH is one of the major tools in what I do. For any developers out there who don’t know about it, you’re missing out. Long gone are the days of requiring screen sharing or remote desktop to manage another computer. SSH is the bomb, and it’s been around for a long time.

Here’s how to use it, without needing to enter your password when you make a connection to a remote machine:

• On the computer you’re making a connection from (i.e. your home computer)
• • If you do not have a ~/.ssh folder already, create one.

  • ssh-keygen -t dsa -f ~/.ssh/id_dsa -P ''

  • scp ~/.ssh/id_dsa.pub <username>@<servername>:~

  • Make an old-skool connection to the server you just copied your public key to (i.e. your public webhost)
• on that server:

• • cat id_dsa.pub >> ~/.ssh/authorized_keys2

  • chmod 0600 ~/.ssh/authorized_keys2

That’s it. Keep in mind, that you’ll still need to specify your username when connecting to the host (if it’s different than your username on your local machine). If you want to get around that, you’ll need to setup an SSH config file (future tutorial?).

Not long ago I got the task of setting up a small server for an engineer in our building. He has a small office with one other person working for him. The idea was for him to have a central repository for files, a system backing up those files, and the ability to remotely access all of those files.

I recommended a Windows SBS 2003 box. The client obliged.

All was fine until the issue of VPN came up. I’ve done VPN’s before, but usually it’s through hardware, not through the OS. The client eventually was paid in full, and the issue still wasn’t completely resolved. I felt terrible about it, so I made it my priority to fix. The client was really cool, and I didn’t want them to feel cheated or upset in any way.

I won’t go through the whole tutorial on how to setup an SBS box, but I will say that usually, it’s very intuitive. Well, when I set up the box, I configured it to work on one subnet. However, the modem supplied to the client wouldn’t allow GRE packets through, so they needed to get a new modem.

When that modem arrived, it didn’t work with their existing Linksys wireless router. So I used the modem as the router, and plugged the wireless box into it, and ran it as a separate subnet. Keep in mind, this was after I had already configured the SBS box for the previous subnet.

I thought I had configured the server to work with the new network settings, but I missed a couple of items.

Clear ARP cache.

Since RRAS was started, you couldn’t clear the ARP cache (the table with the addresses of machines according to the old subnet). I had to stop the RRAS service to clear the ARP cache. Keep that in mind if you have to move an SBS box from one network to another.

Change ALL network settings. When I changed the TCP/IP information for the network adapter (only one), I only changed the information on the front dialog box. Which means I forgot to change the WINS information! Since the client was using VPN so he could navigate to files on the network, that was pretty important.

Also, I needed to add the dns suffix to the DNS settings area as well.

The moral of the story, take the time to get it done right the first time.

All,
Here’s a little story for those of you how support clients running Timberline Accounting software. If you don’t run this sort of thing, don’t bother to read the rest of this. This is a long story!

I got the task to update our Timberline Accounting software from 9.2.1 to 9.4.0. I’m ALWAYS hesitant to do this sort of thing, because it never goes right. However, I was getting pressure from the accounting dorks to make it happen.

FYI…
Engineers = nerds
IT = geeks
accounting = dorks

There is a difference.

Anyways,
So after I dealt with our e-mail issues I wrote to all of you about before, I felt motivated to get this taken care of as well.

First, I had to install the software to the server that holds the data and runs the Pervasive database. Well, for whatever reason, I wasn’t able to install this remotely, so I had to rig up a monitor, keyboard, and mouse to that server to install the app.

The first installation took about 15 minutes, then failed. The failure results in a rollback of the installation. Well, I’m hard-headed. So I installed it again (quite irritated too). This time it worked. However, I was forced to install to a different location than where we used to run the software from. That really sucks, since we map network drives to the data folder locations. So I was going to have to change the network drive mapping to 20 workstations. I run a batch script at login (though group policy) that maps network drives (I’m forcing the disconnect and reconnect for this very reason), so I changed that script, but just to be sure, I did the manual thing for the first workstation.

After the install to the server, the server has to restart. That sucks too, since that server is also our exchange server, and main file server. In other words, all of the users have to stop what they’re doing while the server is restarting.
It was taking forever (shutting down for 10 minutes) so I did a hard shutdown on it (hold power button). That’s sort of nerve-wrecking too. The server started up fine, and I proceeded to the first workstation.

So, I installed the upgrade to the first workstation. It took about 5 minutes, and it failed. I’m still hard-headed so I installed it again, and it worked. There was a small problem however. None of the applications we pay a lot of money for were available. Apparently the second install didn’t catch the registration codes for installed apps.

Grrrr. So I had to modify the server installation to pick up the correct apps, restart the server (another hard restart), and go back to the first workstation. The workstation picked up the available apps without reinstalling (great). then came the task of updating the data files.

2 hours later…

Did I mention nobody can use Timberline while this is going on?

I went to the next workstation to perform another install (just to make sure I wasn’t going to face any problems doing this remotely. I live in Orlando and it was time to go home.). Sure enough, the upgrade wouldn’t take, even after 4 attempts. I kept getting an error about an uninstall log not being found.

So I figured it was the exception, and went to another workstation. The first install failed, the second worked.

I drove home, figuring to finish remotely.

I got home, connected to the server, then to a multitude of workstations (I love RDP). Several of the workstations had the problem about the uninstall log not being found. So, I faked it. I created the directory, performed the install again, and it worked. I got all of the workstations upgraded, and had a well deserved good night’s sleep.

The next morning, I tried the install on our terminal server. Nothing worked. Even worse, I had forgotten to upgrade the CFO’s version of Timberline. When I did, I got a new error!!!! This one was a JIT debugging error that a registry subkey tree couldn’t be deleted without a subkey existing.

I could feel the office resentment for me building.

The terminal server upgrade HAD to be installed at the console. Well, I was in Orlando, and not about to drive back to West Palm to make it happen. I had one of the employees plug in a monitor, keyboard, and mouse to the terminal server. The employee did, and nothing came up on the screen. A check of device manager revealed a bad display driver. I looked everywhere for a driver (ATI 3D Rage Pro PCI) for win server 2003. The most recent driver was for win98SE!!! Hey, my company can be cheap, just ask Chuck.

After a while, I figured I could get someone to logon blindly, and I could remote control the console session. That worked! I performed the upgrade once, it failed, then I did it again, and it worked.

I had to call Timberline support for help with the CFO’s install. We didn’t buy the phone support package, but I figured since we did just shell out some good cash for the upgrade, they’d help me anyways. I was right. For the record; Timberline has EXCELLENT tech support. The tech on the phone with me directed me to a windows installation cleaner application. It’s provided by Microsoft and it fixed the subkey tree problem. I didn’t even have to install twice to the CFO’s machine. You can check it out at the following link:
http://support.microsoft.com/kb/290301

Next disaster, the CFO uses a data mining program called Monarch to pull our Timberline data into composite models to see where we stand across company subsidiaries. That program uses ODBC to connect to the Timberline data. The ODBC connections weren’t working. The CFO mentioned that he used to be prompted for a username and password when he connected to the data, but now he wasn’t.

I checked into this, and it turned out that all applications were available to all users. That’s a problem. Not just anyone should be able to look at payroll files and arbitrarily give themselves a raise. A quick look showed that when I copied over our data files to the new location, I failed to copy the security definition files. A quick fix, but that still didn’t fix the ODBC problem faced by the CFO.

I checked everything for this. No solution. I wound up with a huge headache from the stress. Enough of a headache that I was vomiting for an hour. I took a nap (2 hours) and went back to work. I need to learn to handle stress more effectively. My wife suggests we take yoga together. I’m thinking about a Guinness.

This morning I kept searching around for a solution the the ODBC problem. The CFO was hinting that maybe we should roll back the installation if we couldn’t get the DSN’s to work. I couldn’t even begin to fathom the nightmare that would entail.

I mustered up the courage to call Timberline tech support again. They work out of Oregon. So when I called at 9:00am, it was 6:00am there. The screener that I spoke with kindly forwarded me to a tech and within minutes he had the ODBC problem solved. Remember the situation I spoke about with the applications not being available to users, because I had failed to enter the registration code for them at the server? Well usage of the ODBC driver isn’t free either, though the tech gave me the code over the phone.

So, I had to have an employee rig up a monitor, mouse, and keyboard to the main server, and log on as the administrator (yes, I gave them the administrator password). They started a console session which I took over. I modified the installation, entering the registration code for the ODBC driver, restarted the server, and was done.

Did I mention that ALL of the workstations have to be restarted each time they are upgraded?

Well now everything is working better than before. I’ve kept my up my job, and kept down my lunch.

In summary….

• Do your upgrades over the weekend, when no one is around to care.
• Take the time to read the manual.
• Resist upgrading anything at all costs.

Thanks,
Cory