Tag Archives: ssh


For -years- I have hoped and searched and wished and moaned for lack of a halfway decent terminal emulator on Windows. Specifically, one that:

  1. Lets me use my standard unix toolset.
  2. Gives me a command line interface to the host machine WITHOUT requiring me to do something ridiculous like ssh’ing to localhost or firing up an x11 server…
  3. Realizes that sometimes the display is wider than 80 characters…
  4. Provides customizable color codes (#006 on black really stinks).
  5. Doesn’t set TERM=something-nobody-supports.

One wouldn’t think this was too much to ask. But none of the major open source projects of which I am aware provide this. I even tried my hand at writing one myself but got distracted before it was any good.

So, for years, I have used Cygwin xterms and rxvt as a mildly tolerable alternative to, well, nothing.

Today, a coworker and I discovered a 3-year-old blog post promoting Console, a GPL licensed CMD.exe replacement that matches all of my base criteria plus my big dream feature of tabs. TABS!

Console2, Where have you been all my life?!

The project is ancient – but I was using linux desktops for work back in its early days so that probably accounts for my missing it back then.

In the grand tradition of old Sourceforge projects, there is no installer. You just decompress it somewhere and run the exe directly.

When I launched it the first time, I was unsurprised by the 80×25 courier 10 cmd.exe shell it launched by default. I opened the settings menu and was very very pleased with what I found on the first screen. A few minutes later, I had it pointing at my cygwin install:

And a few minutes later:

Continue reading console2

shared key gotchas

This is something that has kept coming back to bite me recently.

When you are setting up public-key authentication on OpenSSH, you must be very careful of file ownerships and permissions. In many stock unix setups, this isn’t a problem. But in any environment where you are relying on a lot of group access to files, it is easy to slip up and earn yourself a system that will silently fail to authenticate (unless you turn on debug level verbosity).

  1. The private key must be readable only by the user initiating the connection.
  2. The authorized_hosts file must be writable only by the account accepting the connection.

Sounds simple enough, ne?

The real trick is that group write permission anywhere up the directory tree can render these precautions meaningless. Who cares if I can’t see into .ssh in your home directory if I can manipulate your home dir itself?

  1. $HOME and $HOME/.ssh must be locked down on the destination host.

A general good rule of thumb for permissions might be something like this:

Obviously, this gets kind of tricksy if you want to do something like allow SCP file transfers to the Apache user on a system… and their home dir is /var/www… and your web developers have group write access to this dir.

In situations like that, you have two options. First, you could disable the permissions checks (by turning off StrictModes in the sshd_config), but that’s not advisable. Second, you could make a separate home dir for the apache user with the restrictions in a place where they won’t interfere with anyone’s work.

ssh.com vs openssh

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:

  1. 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.
  2. 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…
  3. 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:

  1. 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.
  2. 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.
  3. Convert the file into a format suitable for OpenSSH.

    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.

shared key ssh authentication

SSH supports a number of different methods of authenticating connections. The two most common are password and shared key (and I’m not going to talk about the others, since they’re for rather specific applications). By default, and in almost every case where people use SSH, they’re probably entering a password. This is generally good for security, but bad for convenience, scripting, and a number of other things.

When setting up shared keys between two accounts, there is only really one big decision to be made – do you want to require a password or not? If you do so, that password is independant of either the source or destination accounts’ passwords. If you don’t set a password on the key, you effectively merge the two accounts into one – making transitions between them very transparent in deed.

I tend not to set passwords on my ssh keys. This means that I can scp files between machines without having to type the password every time, which in turn means that I can run backup scripts over an encrypted connection or use gvim to edit a remote file securely without having to tunnel an entire X session. There are lots of uses.

But I digress. You just want to set it up, eh?

Suppose I am setting up passwordless stuff between two servers, Bender and Fry. The basic procedure for creating my key pair looks like this:

Obviously, your username & hostname are probably going to be different, as is the generated fingerprint. This creates two files, ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub. These are your private and public keys (respectively). And, because you didn’t type in a password when creating them, they’re not going to ask you for a password when you want to use them.

In addition to creating an RSA key, you could also create a DSA key, but RSA keys work with both SSH1 and SSH2 (not that you’re using SSH1, right?). For our application, there’s no real reason to choose one over the other.

Now that we have our keys, you need to send the public key to the other server. The SSH daemon looks for public keys of friendly accounts in ~/.ssh/authorized_keys, so the process is probably going to be something like this:

Now, if the universe is right, when I try to ssh over to Fry, I won’t be prompted for a password. To make things happy the other way around (to allow Fry to log in to Bender w/o a password), you just repeat the process the other way around. That is, create a key pair on Fry, copy the public key over to Bender.

If we were to add another server (Zoidberg) to the list, you’d repeat the process by creating a keypair over there and copying the public key to both Fry and Bender, and making sure Zoidberg’s authorized_keys file contains a copy of both Fry’s and Bender’s public keys. The more machines you add to the mix, the easier it is to forget to update one.

I find it helpful to make a copy of the public key in the form hostname.pub when generating a new key and copy it everywhere. Then, on the remote machines I execute a cat *.pub > authorized_keys to regenerate the index.


And, just because I am such a good citizen, I figure I’ll close out with a warning. Be careful with this, if one machine in your little family of key-sharing happiness is compromised, the rest are. Also, it is healthy to keep track of which accounts can talk to which other accounts in order to track down/make changes in the future.

Case study:

At a previous job of mine, I had set up passwordless shared key ssh into the root account of one of the (non-mission critical) servers from my desktop, since that was the only place I was logging in from, and I was doing it a lot.

Well, 9 months after I quit, I typoed an ssh command – and wound up with root privs on the box. My brief examination of the machine showed that while the guy who replaced me was bright enough to change the root password itself when I left, he didn’t check for ssh keys. I discovered three other accounts that were similarly accessible by keys created by users who were no longer with the organization.