SSH + Public Key Configuration

One of the questions I find myself answering frequently is: “How do I configure SSH to authenticate me via multiple public keys?”  Many of my fellow grad students have multiple computers — I have my personal laptop, an ASU-owned iMac, and a second personal laptop for backup if something should happen to my primary machine.  I need to connect to many unix-based version control servers, web app servers, etc.  SSH public key authentication provides a way to make this much safer and more secure.  These instructions are for OS X, but I’ve used the same commands successfully on various Linux distros as well. On Windows, you’re on your own for the client side (try e.g. the PuTTY docs, if that’s what you use), but the remote side will be identical. Here’s how to set this up.

First, if you haven’t already, generate a key pair on each machine you want to set up to log in.


$ssh-keygen -d {rsa, dsa}

Pick either RSA or DSA cypher by entering rsa or dsa in the command line. I personally use RSA; some of my friends use DSA. It works either way, and the differences in encryption are out-of-scope for a how-to.

You will be prompted to enter a passphrase. You can leave the passphrase blank (which will allow you to log in without entering any credentials at all) but be advised that this is NOT secure — anyone who compromises your local machine and gains access to your private key will have immediate access to anything authorized with your public key. Sometimes the convenience outweighs the risk, sometimes not. Be wary.

This command will generate a private/public keypair, and place them in ~/.ssh/id_{rsa,dsa} and ~/.ssh/id_{rsa,dsa}.pub on your local machine.

If your remote account has a different username than your local username, you can save some typing by setting up a default remote username.  Edit ~/.ssh/config and add an entry like so:

Host my.remote.host
User myRemoteUserName

This tells SSH that you want to use myRemoteUserName as the username any time you connect to my.remote.host (which should be the domain name or IP of the server you’re connecting to).

With that configured, you need to copy your public key (~/.ssh/id_{rsa,dsa}.pub) file to the server.  A word of caution: DO NOT COPY YOUR PRIVATE KEY (~/.ssh/id_{rsa,dsa}) file. EVER. The security of this scheme depends on your private key remaining private.  To copy your public key, use the following:


$scp ~/.ssh/id_{rsa,dsa}.pub my.remote.host:~/my_public_key.pub

This code copies your id_{rsa,dsa}.pub file to your home directory on my.remote.host, and gives it a descriptive name.

Now you want to add your public key to the list of authorized keys on the remote machine. This is the tricky bit: you do not want to overwrite that list of keys if it already exists. To do so: first, ssh into your remote server:

$ssh my.remote.server

You will still have to manually enter your account’s password — we’re not finished yet.

Now, the coup d’gras. On the remote server:

$cat ~/my_public_key.pub >> ~/.ssh/authorized_keys

This is actually a couple of commands strung together. Cat says “print the contents of this file to stdout.” The double caret operator (>>) says “append the output of the command before me to the file specified after me.”  The ~/.ssh/authorized_keys file contains a list of public keys that are authorized to log into this account.

It’s also possible to copy my_public_key.pub to ~/.ssh/authorized_keys, or cat with a single caret (“>”) but either of these methods completely overwrites authorized_keys. What you want is to append the new public key to the existing file.

You can repeat this process on as many client machines as you like, and give them all access to the remote server (my.remote.host in this example) via public key!

Posted in Uncategorized | Leave a comment

Welding Results!

As part of the Smart Environments project at AME, my colleague and friend Andreea Danielescu and I are designing and building LED-based indirect lighting fixtures — you can see a first-iteration of the concept using incandescent bulbs documented on the Building with a Memory site.  We received a grant through the ASU GPSA’s Graduate Research Support Program to support the design of slimmer, more energy-efficient, brighter panels as part of the build-out for the opening of the new Digital Culture building at ASU. One of the enhancements in the new panel design is the use of lightweight aluminum for each fixture’s frame, which gives us reduced weight, enhanced strength, and better thermal characteristics than the MDF frame I glued up for the first-iteration panels.  This means I have to get acquainted with TIG welding again, since I haven’t picked up a welder since my senior year at Cornell.  The results aren’t bad, for a five-year gap in experience:

Good weld!

Posted in Development | Leave a comment