Compass Version1.1

TOC

Setting Up SSH Keys

WARNING
This method of setting up SSH keys is not the most secure method and should NOT be used for general 
purposes.  It is intended only to be used within a LAN or behind a protected firewall or when 
security is not of primary concern.

Several projects that use Compass use their source-control tools with secure URLs or via the svn+ssh protocol which relies on ssh to communicate with the server. When using ssh to perform any communication inside of a Compass build step it is critical to set up SSH keys to automatically authenticate. If SSH keys are not set up, then build steps that use SSH will appear to hang indefinitely because build steps have performed an SSH command and they are waiting for a user to enter their username or passphrase. In order to have SSH not ask for passphrase and usernames, the user that is performing the SSH command must set up SSH keys with the server to automatically authenticate. The most common situation where SSH keys need to be set up is:

We have a user with the username joe. joe wants to be able to SSH from the computer at his workstation named MY_BOX to a source-control server named CODE_SERVER without entering his passphrase. To set up an SSH key that lets joe access CODE_SERVER from MY_BOX without entering his passphrase we need to create an SSH private and public key for joe on MY_BOX.

To set joe up we first need to ssh to/from each box. If joe has never ssh'd from either CODE_SERVER or MY_BOX then he needs to do that first. So sitting at MY_BOX we tell joe to ssh from MY_BOX to CODE_SERVER and then ssh back to MY_BOX. we do this to let SSH create a .ssh directory in the joe's home directory:

MY_BOX> ssh joe@CODE_SERVER 
joe@CODE_SERVER's password:

Joe enters his password and now he's logged in to CODE_SERVER. Then we have him ssh back to his workstation:

CODE_SERVER> ssh joe@MY_BOX
joe@MY_BOX's password:

Joe enters his password again and now he's logged back in to his workstation (but through the CODE_SERVER) so we exit twice to get us back to his box again:

MY_BOX> exit
CODE_SERVER> exit
MY_BOX>

Now, both MY_BOX and CODE_SERVER are gauranteed to have a .ssh directory in Joe's home directory. The next step is to create an SSH keypair on Joe's workstation. We use ssh-keygen to do this:

MY_BOX> ssh-keygen -t dsa

This will ask Joe to enter a file to use to store the keypair in, we tell joe to hit enter to use the default. It will then ask for a passphrase and for a confirmation, because we want to not enter a password every time we ssh, we just hit enter to use no passphrase. This is where we have a potential security issue, because anyone that sits down at MY_BOX and is logged in as joe will be able to ssh to CODE_SERVER without a password. After joe hits enter twice he is returned to his shell prompt. At this point we now have 2 files in the .ssh directory, id_dsa and id_dsa.pub.

id_dsa is the private half of the keypair, this file needs to stay safe on joe's computer and he should not share it with anyone. id_dsa.pub is the public half of the keypair and joe can give his id_dsa.pub file to anyone he wants. To copy the public key to CODE_SERVER joe first needs to secure copy it there:

MY_BOX> scp .ssh/id_dsa.pub joe@CODE_SERVER/.ssh

Now, joe has to ssh for the last time from MY_BOX to CODE_SERVER and enter his password:

MY_BOX> ssh joe@CODE_SERVER
joe@CODE_SERVER's password:
CODE_SERVER>

Now, joe has to copy his public key into the ssh authorized_keys file:

CODE_SERVER> cat .ssh/id_dsa >> .ssh/authorized_keys

And that's it! Now every time joe ssh's from MY_BOX to CODE_SERVER he will NOT be prompted for a password.