GitHub Pages

Did you know we are releasing source code for download? The first three projects already have full websites you can check out.  MOEAFramework is an open source platform for MOEAs and diagnostic tools.  The Borg MOEA is our new auto-adaptive MOEA framework which has been shown to solve difficult problems.  And DecisionVis is a new company specializing in visual analytics for many objective problems.

We are also starting some exciting new open source projects.  The idea behind these projects is that folks can see source code and collaborate on interesting new research with an existing code base.  In today’s post, I want to share the instructions for how to get started with GitHub pages.

I followed the documentation on GitHub’s website.  The tutorial shows how to use GitHub’s “automatic generator” to create a nice sample page.  First, I created a blank repository called   In the Windows version of the GitHub software, this is as easy as “point and click”.  Then, I navigated to this repository on the GitHub website, clicked the Settings tab, and then followed the instructions for the automatic generator.  The page was then created at

Note! You can create a page for your entire user site (see above), or for an individual project! To create a project page, simply navigate to the “Settings” tab of an individual project.  Then, the rest of the procedure is the same.  For our group project pages, we like the “Tactile” theme (see an example here).

The nice thing about this service, is that you’re not really limited in what the page contains or what it looks like.  It seems like other programmers are using their pages to host blogs.  For example, I enjoyed this blog.  It seems as though most GitHub Pages are created using a platform called Octopress, which suits itself well to using Git for content updates.

Making ssh better

If you use ssh to work on remote systems, you may find yourself doing a lot of repetitive typing and password-entering. Fortunately there are some easy steps you can take to avoid these problems and make ssh really, really easy to use. Not that it’s too difficult in the first place—but if you use it often enough, this is worth it.

(Thanks to Matt Woodruff for figuring this out!)

1. Set up a ~/.ssh/config file

A normal ssh login would look something like this:


If you’re like me, at some point you will lose track of your username, host address, or both. You can set up shortcuts for these addresses by creating a file ~/.ssh/config that looks something like the following:

Host foo
  User my_name
Host bar
  User my_name

Now instead of typing ssh, you can just type ssh foo to log in. This is especially useful with commands other than ssh that use remote addresses. For example with this config file set up, you can do things like:

scp ./local/path/to/file foo:/remote/path/to/file

You might also consider adding GitHub to your ~/.ssh/config file like so:

Host gh
  User git

Usually you would run, for example, git pull But now you can just do git pull gh:/my/repository.git. Pretty cool. One last thing to note, make sure the permissions on ~/.ssh/config are set to 700 (only you have r/w/x permission). Some systems will refuse to use the file otherwise.

2. Use ssh keys to log in

There are a few reasons to switch from password login to key-based login. One is security, since someone would need your private key file to log in, which (should) only exist on your computer. The second is to avoid typing passwords all the time, which you’ll see in the next step. To create a public/private key pair in your ~/.ssh/ directory, run:

ssh-keygen -t rsa

By default this will create files id_rsa (your private key) and (public key). Never, ever copy your private key anywhere else. If you want to create these files with a name other than the default, use the -f flag to specify a name. When you create your key, you will be prompted to enter a password. If you leave it blank, there will be no password for the key, but it’s a good idea to stick a password on it anyway.

Now that your key pair exists, you can copy your public key to any remote systems that you want to access:

ssh-copy-id -i ~/.ssh/ remote_user@remote_host

The public key will be appended to the file ~/.ssh/authorized_keys on the remote host. Note that you can append multiple public keys to this same file. For example, you may have one key for your home computer, one for your work computer, etc.

If you want, you can also set up ssh keys on GitHub. Go to Account Settings -> SSH Keys and click “Add SSH Key”. Choose a name for the key, and copy the contents of into the box. (You can run cat to view the contents of the file). Once you start using key-based login for GitHub, it will stop letting you log in with a password, so you may want to wait until you have ssh keys set up on all of your systems before making this switch.

3. Run ssh-agent for password-less login

So we have a key-based login set up, but we still need to type the key password every time we use ssh. This can be very annoying if you’re using a lot of git commands, for example. One way to avoid this is to enter the password once at the beginning of your session, and have ssh-agent manage the password for you:

ssh-agent && ssh-add

You will be prompted to enter your password once when you run this command. But, in all subsequent ssh commands, you will not need to enter your password at all. Note if you’re using screen to spawn multiple shell instances, you will have to run ssh-agent in all screens separately. Personally, I have this command aliased like so in my ~/.bashrc file:

alias key='eval `ssh-agent` && ssh-add'

That way I can just type “key” once, enter my password, and have ssh-agent manage my password for the rest of the session.

You may not need to do these things if you’re an infrequent ssh user, but at some point, the time saved with this setup will be well worth it.