May 28, 2008 by Justin
After many months of development, I'm pleased to announce that Meerkat is ready! As the tag line goes, UNIX power, Mac style: SSH tunnels made easy. Meerkat is an easy to use SSH tunnel manager built specifically for the Mac. A lot of blood, sweat, and tears has gone into this release and I'm happy (and relieved) to get to this point.
If you're reading this on the actual site, you may also notice that I've redesigned the website. I hope that it makes more information available, while staying uncluttered and more easily manageable.
Lastly, I've also moved from WordPress to Drupal as my content management system. There are many reasons why, and I hope to blog about them in the near future, but for now, please do drop me a line if anything seems to be out of place.
And now, go get Meerkat! :-)
Trackback URL for this post:
https://codesorcery.net/trackback/127
- Login to post comments
RSS feed for comments to this post
Congratulations to releasing
Congratulations to releasing a new software product!
The site redesign is also great, but I would do one more thing: make your software more prominent on the home page. My first thought were these small images with Apple products below the main ad on the official Apple page, possibly you can do something similar?
@Rafael: Thanks for the
@Rafael: Thanks for the feedback. That's a great idea and I think I will look into it.
Been dying to get my hands on
Been dying to get my hands on this forever - downloaded tonight and started experimenting. Seems to work fine with VNC and Remote Desktop, firing up and shutting down tunnels as apps start and stop. But following (exactly) the example from your initial Meerkat blog post for remote access to iTunes by forwarding port 3689 isn't working as expected. The tunnel opens, and the remote library appears in the iTunes' menu pane, but clicking it returns "The shared library is not responding (-39). Check that any firewall software running on either the shared computer or this computer has been set to allow communication on port 4000." When I have the laptop I'm now experimenting with connected on the same LAN as the librsry I'm trying to access, iTunes can access it without any problem.
But I love the app-triggered tunnels. Juat gotta get 'em tweaked to do what I need.
This looks like a nice app,
This looks like a nice app, but before I replace my launchd autossh script, I think it needs one addtional feature. I tunnel 5 or 6 services, each on a different port, to the same user@host ("Account," in Meerkat terminology). Rather than launching a different ssh process for each forwarded port, as Meerkat 1.0 does, it'd be great if Meerkat combined all those common forwards into a single process, like this:
ssh -L 8080:localhost:80 -L 3128:localhost:3128 -L 6667:irc.freenode.net:6667 ... bob@example.org
Also, since you're appealing to the security-conscious crowd with this app, you should probably have the source code peer-reviewed by at least a few security experts. That doesn't necessarily mean you need to release the source to the world; if you ask on a reputable crypto mailing list, you can probably find some qualified people who'll review it in confidence. I know I'd feel better about using it if it were peer-reviewed. I'm particularly nervous about the Bonjour support, which, while neat, could be a serious security hole if, for example, there were a bug in the enabling or disabling of that feature.
One other minor suggestion: it appears that Meerkat restarts all tunnels whenever you add a new one. It'd be nice if it didn't do that.
Thanks, and good luck!
Bonjour is the killer app
Bonjour is the killer app here, at least for me, is the Bonjour publishing of the tunnel. ShareTool does a similar thing but is more restrictive although simpler to set-up. However, I too can't get the iTunes tunnel to work correct and get the -39 error as does Hendel.
Couple of feature requests, first a pretty simple one: improve the UI for setting up access to Back To My Mac services. Next is more difficult but I think the documentation and UI needs to be improved to make it _much_ clearer what goes where, use iTunes as the example for at least one case because that is a common use case. Even the wizard still basically asks for the information that you are going to throw into the command line, maybe change the UI to more of a task based approach. Using the iTunes example again, maybe have a radio button "Accessing your iTunes library on another machine". That would auto fill in the ports needed and turn on Bonjour.
Anyone that knows what they are doing are going to use the sheet to get things up and running anyway.
@Nick: I'll be checking out
@Nick: I'll be checking out the iTunes issue to see if anything has changed there. And as for documentation, you've seen the help book, yes? I'm definitely open to feedback, though, and will absolutely improve the UI and documentation as feedback comes in.
Thanks for your comment!
Wow. The application is
Wow. The application is great. I registered it right away. Although the iTunes tunneling doesn't work for me either i still think that the 1.0 version looks so promising that it deserves to be supported.
@Justine. Did see the help
@Justine. Did see the help book and it is fine as far as it goes. My comment was more about providing documentation and wizards for common use cases. While I appreciate the iTunes blog entry that kind of stuff would be great to see in the UI/docs.
Another idea I had was to make Meerkat "Back to My Mac" aware. This is actually pretty simple, all you need to do is use their addressing. For example the living room computer for .Mac user stevejobs is addressable as:
living-room.stevejobs.members.mac.com.
If Meerkat could use Bonjour to find that address (Bonjour Browser shows it) then it could make SSH tunnels to "Back to My Mac" machines easier to set up.
I have contacted you directly about the iTunes issue, but the bottom line is that I don't think it is a Meerkat specific bug.
Really like the concept and
Really like the concept and find Growl and App Triggers highly useful. However I've already got public-key authentication fully working and can use apps like Transmit, sshfs and Terminal without specifying a password or private-key or relying on SSHKeychain. Unfortunately in my testing the current version of Meerkat insists on using password or private-key. Make Meerkat work like other apps and I'll use it and send you money.
@Nick: I take your point on
@Nick: I take your point on the docs. I'll be giving some thought to this.
Regarding the SSH keys, I can rethink how I am doing things here, but to my knowledge, one downside of the way Transmit does things is that you can't use an alternate key other than one named after the standard filename (e.g., id_rsa or id_dsa), unless you first add the key to the agent, which you may not want to do automatically if it requires a password. Meerkat lets you use a particular key, prompting you (via your agent) only upon first use if it is locked. This allows people to use separate keys if they wish, which I've done myself in the past.
And on a security note, a bit about passwords and keys...
When keys are used in Meerkat, all that happens is the private key path is remembered by Meerkat, then added to the SSH command line using the -i argument. Meerkat doesn't read in the contents, although of course as a user space program, it would have access to, just like any other that you run. For passwords, they are added to the keychain for later.
When an SSH password prompt comes back from the server, Meerkat uses a helper program to interact with this and send back the password interactively, terminating upon successful setup of the SSH process. Meerkat then would need to fetch the password from the keychain for the next use, unless you disable the "Ask keychain for passwords every use" preference, at which point Meerkat caches the password in memory for the rest of its launch.
Oh, and I love the idea about
Oh, and I love the idea about Back To My Mac -- will be looking into that as well.
Going back to the my basic
Going back to the my basic issue with Meerkat -- assume I have only one identity and have distributed authorized_keys to all remote hosts. Why does Meerkat demand I supply the path to my private key? While I agree any user-space program can find my id_rsa file the real issue is 'plug-n-play' with environments already setup to use private-key authentication. In addition it did cause me to pause and consider the security consequences of telling Meerkat where to find my private key, which resulted in no sale for you as it didn't work 'out of the box' the way I expected.
Taking it one step further in fact I have two identities and do not use SSHKeychain or ssh-agent (purely out of ignorance). Instead I have a local ssh "config" file (man ssh_config) and one additional identity defined using IdentityFile keyword.
This is a very promising app and for better or worse I want to use it without changing my habits. Give me a convincing security argument and I'll change my ways although I think that means protecting my keys with a password.
Point taken... I have done
Point taken... I have done some testing and you're right, using an identity file without a password and manually specified in the SSH config does not require any interaction with the SSH agent. I just had never tried using a passphrase-less identity while also manually specifying it in the host configuration (which, by the way, is much less secure than an identity with a passphrase -- what if your machine is stolen?) Without the manual specification, you need to use the -i command line option, which is what Meerkat does.
Where were you during my testing process? ;-)
In all seriousness, the problem comes down to interface, in that I want Meerkat to not let you end up with a bum account setup, so I ask for either a password or an identity file so that the account in Meerkat is "complete". There is not a very easy way for me to have Meerkat ensure that things are setup ok otherwise. This would require parsing the ~/.ssh/config file (which, in my opinion, is even more mucking about in the user's personal files) to find a hostname matching that specified in the Meerkat account, and even then, you could have the host specified as "gateway" which, combined with local DNS, could give you the fully qualified hostname of "gateway.mynet.com". There's a lot of complexity there.
The tradeoff is that the one time you setup the account in Meerkat, you have to re-specify the identity file that you already specified in ~/.ssh/config. That's it. And as I said, Meerkat doesn't even read the contents -- it just passes it to SSH using the -i argument, which you can see in the process list.
And just for completeness, the only file that Meerkat does read in is your known_hosts file, so that it can provide autocompletion to the hostname field when setting up accounts.
Thanks for this... eager to hear your thoughts now and I hope we can work something out :-)
And if you are interested in some more information on SSH agent, Meerkat's help book has some info, as well as external links, in the section named "Types of authentication".
And about protecting your
And about protecting your keys with a password, I should add that as of Leopard, OS X includes a built-in ssh-agent process with keychain integration. So you could protect your key(s) but get prompted for the passphrase(s) via a GUI, optionally saving that in a keychain. So everything could still be, after initial setup, without any kind of password prompting, but everything would be protected via the keychain, which could protect you even in the case of machine theft.
Again, more on this is included in Meerkat's help and in some resources that it links to.
Justin, thanks and I'm glad
Justin, thanks and I'm glad you see my point of view. Last night I did some testing using my 2nd private key and after running "ps ax" noticed the long ssh command-line you generate. I assumed you were using SSHKeychain or ssh-agent but issuing "ssh-add -l" revealed nothing.
A very promising app and I'll likely kick some cash your way in hopes of further development.
That would make sense. Since
That would make sense. Since your keys don't have passphrases, ssh-agent is not involved and again, I never foresaw that circumstance. If it has a passphrase, on Leopard at least where ssh-agent is already running, the key would be added to the agent, prompting you for the passphrase via an ssh-agent GUI.
Justin, thanks. Somewhat
Justin, thanks. Somewhat irrationally I like that output of "ps ax" is simple doesn't show path to private key when running Terminal/Transmit/sshfs (using my ~/.ssh/config method for alternate private key). For Meerkat I'd really like to see output of ps revealing "ssh -F ~/Library/Application Support/Meerkat/nickname_config" although admittedly its not a real security issue.
This entire discussion has convinced me to use passwords with my keys, and that I should migrate to that as soon as possible.
Registered and sent money.
Registered and sent money. Keep up the good work!