It’s handy to establish an SSH key between machines so that SSH-related commands don’t prompt you for a password. This is handy to quickly SSH into another machine, and it’s even more handy when setting up SSH commands in automated scripts. For instance, you may want to execute some rsync statements in a script that runs on a regular basis. It’s better to have an established SSH key between the two machines than to have a password embedded in the script.

I recently reinstalled the OS on one of my Macs, and I’ve got backup scripts on my CentOS Linux box that use rsync to back up some pertinent data, so I had to reestablish the SSH key between the machines and had a hard time remembering how to do it. So this time I’m documenting what I had to re-learn.

First of all, there’s a great post over at nixCraft that basically explains how to do it. But allow me to explain more thoroughly, ahem, dumbed down to my level. 

The key is remembering which machine is filling which role when you’re reading the instructions. I’ll call them the “Acting” machine–the one who is taking action and performing a command, let’s say an rsync command–and the “Target” machine–the one who is being acted upon. In my case, the Linux server is the acting machine performing the rsync command, and my Mac is the target.

The process is simple. On the “Target” machine, generate a key, and then give that key to the “Acting” machine, which effectively gives it “permission” to login without the need to supply username/password credentials.

So, from the “Target” machine, in this case, my Mac, type the following command:

ssh-keygen -t rsa

This will generate a couple files that serve as a key for accessing the Mac. The ssh-keygen command may ask you where to store the key and what password to use. Just hit enter to use the default path and a blank password.

Next, still from the “Target” machine (my Mac), type:

ssh MyUsername@ActingServer ”mkdir .ssh”
scp .ssh/id_rsa.pub MyUsername@ActingServer:.ssh/authorized_keys2

In the code above, MyUsername@ActingServer would be the username and address (for instance, perhaps the IP address) of the “Acting” machine, in my case, the Linux server. In the first line, you’re just creating the .ssh directory if it doesn’t exist. In the second line, you’re copying the key you generated from the “Target” machine to the “Acting” machine, or from the Mac to the Linux server.  Note that the scp command will ask for the password to the MyUsername account because it is connecting to that server to send it the key.

Voile. As if by magic, the “Acting” machine should now be able to SSH into the “Target” machine without a password prompt. Correspondingly, you should be able to perform rsync and other SSH commands without a password prompt. Please note, however, that this is only a one-way key. We only gave my Linux server permission to access my Mac.

What if I want my Mac to similarly login to the server without a password prompt? In that case, the Mac and the server have effectively switched roles; the Mac is now the “Acting” machine and the server is the “Target” machine, so we just have to repeat the process from the other direction. Generate a key from the server and send it to the Mac. At that point, both machines will be able to access each other without a password prompt. 

What if I have multiple “Targets” that the “Acting” machine will connect to? For instance, perhaps I have multiple Macs, and the Linux server is running scripts on all of them. When you’re sending the key to the “Acting” server with the scp command, use a different name for each key file, don’t overwrite the same file each time! So in the example code above, we’re sending the key as “authorized_keys2″. When repeating this process for multiple targets, send the keys as “authorized_keys3″, and so forth.

Hopefully this will clear up some confusion regarding this process.

Like I have done in the past, I am declaring radio silence today. I will not be check my feeds, look at any Apple news sites, or check my personal email until I can view Apple’s video stream of the WWDC keynote. 

You can view the MacRumors WWDC 2008 Spoiler Free news page if you want to do the same.

So, with Apple preparing to hold an iPhone Software Roadmap event this Thursday, people are eagerly anticipating news about how Apple will handle an SDK for the iPhone environment.

Many developers were frustrated–and many web developers had our curiosities pleasantly piqued–when Apple initially announced that “software” would be available for the iPhone in the form of Ajax web applications. Naturally, many of the disappointed folks were irritated because the web platform is something that they’re entirely unfamiliar with, probably having backgrounds in Objective C or something similar; probably a minority were disappointed because their target application legitimately could not be powered by HTML and Ajax.

That said, it is indeed a very thought-provoking concept: Using web technology as your application environment. As most web developers will attest to, there honestly isn’t that much that a typical application does that cannot be accomplished with web technology. With the advent of Ajax frameworks, applications built with web technology can have very similar responsiveness and dynamics of a “classic” application. Especially when you remove the burden of cross-browser compatibility, in the iPhone’s case.

But with the iPhone/iPod Touch scenario, it is irritating that the application has to reside in Safari and has to be loaded off the web. It almost feels as if Apple was trying to push something that wasn’t…quite…ready. Something like AIR!

AIR accomplishes everything that Apple was suggesting for the iPhone environment, but for the desktop. Use web technology, but write a “compiled”, stand-alone application that really doesn’t even have to use the web. Use HTML. Use Ajax. Use Flex and Flash. Have a nice encapsulated application on your desktop. Especially when you throw the Flash technology into the platform, it is now a very capable environment for a large variety of applications, without being constrained to the browser. Wouldn’t it be great if that same cross-platform environment, AIR, worked on the iPhone as well?

Oops, Flash technology isn’t currently supported by the iPhone. That is actually another source of contention. And the AIR environment does lose some of its punch without Flash and Flex, even though its HTML/Ajax implementation can do a very decent job with most typical applications.

Steve Jobs has made it clear that he likes the idea of web technology powering iPhone apps. Now, consider some of the facts. Apple announces the iPhone SDK will be released in February, and then fails to deliver. Meanwhile, Flash still isn’t found on the iPhone, and Adobe “invents the wheel” by getting web technology to drive native apps through its work with AIR. Is there a common theme with these events? Perhaps something like: Are Apple and Adobe working together to get the much-needed Flash technology onto the iPhone and, subsequently, releasing an SDK that uses AIR technology, with hooks into the iPhone system just like AIR currently has hooks into the Linux, Windows, and Mac OS X desktop operating systems?

It wouldn’t be the first time Apple has had to wait for its partners, or take the heat for them. For instance, Apple has clearly been taking a lot of heat for many factors of the iPhone that are clearly not in Apple’s interest, but in AT&T’s.

And this scenario would fit the circumstances around Adobe’s development of AIR. Adobe has been working on AIR since well before the iPhone was released, but AIR wasn’t officially released until February 25, 2008. Even if Apple and Adobe were working closely together, there just hasn’t been enough time for AIR to get released and hooks to be developed to provide iPhone-specific functionality in AIR. Adobe has understandably concerned itself with its own business first. With that done, attention can turn to Apple to support them in concluding their own business.

Of course, this prediction is a reflection of my own desires as much as it fits the circumstances. As a developer that uses Adobe technology including Flex and AIR, and an Apple enthusiast for more than 20 years, I would love to see things happen this way. Undoubtedly we will have a clearer idea of Apple’s iPhone development roadmap after this Thursday.

As if the thought of an “iPhone AIR” isn’t confusing enough.

I couldn’t understand why everything on my new iMac started creeping really slow. The last straw was when iTunes started skipping.

I opened up the Activity Monitor in the Utilities folder, set it to view “All Processes”, and noticed that a process named “PrintJobMgr” was using a lot of processor time and took up over 600MB.

As it turns out, this has been discussed on Apple’s forums. It seems to be happening to people when there is a print job that never was printed, and thus is continually waiting in the print queue. I’m not sure how, but this is exactly what happened on my iMac, and deleting the print job in the queue fixed the problem.

I’m hoping Apple fixes that one soon.