A few months ago, I wrote a brief entry on how to set up shared key authentication with OpenSSH.
With my current job as a Flash developer, I’m kind of stranded in a Windows world where I am stuck using different ssh clients. The two most popular ones out there (that I am aware of) are PuTTY and SSH.com‘s client. I was introduced to SSH.com’s client back when I worked the support desk at the University a few years ago and wasn’t all that impressed, but it has improved since then, and I like it quite a bit more than PuTTY now.
~funny story
Not to say that SSH.com’s client is perfect. In fact, the commercial release was downright unstable when I tried it out. They let you do 30 day trials of the program. I downloaded the trial of their 5.0 client, installed, and fired it up. Right away, I noticed three things:
- It doesn’t really look all that different (or seem to offer major feature enhancements that the average customer would be interested) from the free 3.x line.
- It installs some sort of random system tray application (probably for management of keys, headless sessions, or something else along that vein) in addition to the normal client. I never figured out exactly what it did because…
- The system tray application is very flaky and likes to blow up at the slightest provocation. Like firing up the client or mousing over the tray icon or looking at the monitor or breathing. But it’s apparently not even necessary to normal function of the application anyways.
So… I decided I’d be nice and give it half a week to shape up. It didn’t. And I honestly couldn’t find any features that were different from the 3.x version that I normally use, except the possibile something that might have been hiding in the system tray but crashed any time I tried to investigate
So, I uninstalled and returned to using the older, free version (which you can download from them here) with no backward glances or sense of loss.
A month passes and I get a phone call from a sales rep. He asks me if I am, in fact, the person who signed up for an evaluation of their commercial client program. I admit that I am, and that I returned to using the older version after less than a week because of general flakiness. I go on to explain that I’ve been a loyal user of their free client for the past several years and that I was a bit amazed that the 5.x client didn’t work reliably.
And he, in turn, admits that there were known problems with that version
What followed was a bit more pleasant conversation that ended in his asking me to give it another try when the next version rolls around. *grin*
Given the lack of visible improvement between the 5.x and 3.x lines, I really see no reason to do so. I’ll continue using the older version until something incredibly better comes along.
using ssh.com’s key pairs to auth against an openssh server
My biggest (and really only remaining) problem with the SSH.com client is that their public keys don’t work with an OpenSSH server (the only thing I really ever log in to)… without some minor tweaking.
The procedure for getting key based auth working between the two goes something like this:
- Create a key using their client. – Go to “Edit -> Settings -> Global Settings -> User Authentication -> Keys”. Click “Generate New…” Follow the prompts and watch the cheesy little entropy animation. The default options are good. Just remember that if you’re doing this to be lazy, don’t specify a password.
- Upload the key to the server. – If you’ve got an active connection to an ssh2 server, there’ll be a big button that will magically copy the file to the server for you. The default location is under ~/.ssh2. Note that OpenSSH stores its keys in ~/.ssh, so you shouldn’t have problems with overlap.
- Convert the file into a format suitable for OpenSSH.
ammon@zoidberg:~/.ssh2$ ssh-keygen -i -f hermes.pub > ../.ssh/hermes.pub
This will give you a file that you can then append to ~/.ssh/authorized_keys so your server knows to let you in.
It is also possible to take an existing OpenSSH public key and convert it for use on an SSH.com server… (just invert the ssh-keygen call by using -e to export the openssh.pub file in stead of -i to import the ssh.com.pub), but who’d want to do that?
What you can’t do is use ssh-keygen to convert an OpenSSH private key to an SSH.com private key. You have to create your key on the same platform as the client you’re planning on using.
It’s been about 6 1/2 years since you wrote this post. So, I’m curious if you’re still using the proprietary SSH client, or if you’ve switched to PuTTY. In fact, I’m curious if any of the SSH servers you work on are proprietary SSH servers, provided by Tectia, HP or otherwise, or if they’ve all switched over to OpenSSH.
I still use the free old pre-Tectia client for 99% of my ssh from windows boxes. It does everything I need and is a lot friendlier than putty – which you’ve got to admit is a pile of programmer ui. If I have cygwin on a box, then I’ll use openssh from the command line. If I don’t, then I’ve very rarely been known to use ssh.com’s command line client from a dos window for one reason or another. The only time I ever use putty is if I’m rdp’ed into a windows server that I need to then ssh out of (such as to get around a firewall), or if I find myself stranded on an alien machine and don’t want to run an installer. If I’m on a unix box, then naturally it’s openssh in a terminal.
I don’t think I’ve ever logged into a proprietary ssh server – EVERYTHING I use both personally and for work has been openssh for as long as I have been aware.