Last modified: Mar 26, 2014
This is a self-assessment activity to give you practice in working with the git version control system. Feel free to share your problems, experiences, and choices in the Forum.
ssh keys provide a way of identifying yourself that is generally more secure than simple passwords. Based on one-way cryptography, an ssh key has two parts: a public key and a private key. You can distribute the public key to a variety of server systems that you like to log in to. You keep the private key on client machines that you log in from. Often these client machines are ones you have a certain amount of physical control over — a home computer or a laptop that you own. That physical security is coupled with a lengthy passphrase needed to activate the private key. Once activated, the private key can be kept active through a work session, allowing you to repeatedly log in to clients that have your public key.
The ssh-keygen program is most commonly used to generate public/private key pairs. Most Linux systems will have this already installed. On a Windows CygWinsystem, you can get it as part of theopenssh` package. [1]
To generate a key pair, give the command
mkdir ~/.ssh # if you don't already have this directory chmod 700 ~/.ssh ssh-keygen -b 2048 -t rsa
You can change the name if you like. (I keep different key pairs for different client machines and name them accordingly, e.g., “officePC”, “homePC”, etc.). Do keep it in your ~/.ssh directory, however.
You will be prompted for passphrase. This is used to protect your private key in case someone gains access to the machine/account where you have it stored. Do choose one. Even though the command prompt says it’s optional, you don’t want to have an unprotected private key around. Most people use much longer passphrases than a typical password, but generally place less emphasis on odd character substitutions that make the phrase harder to type.
Now look in your ~/.ssh directory. You should see your new keys. One file has the extension “.pub”. that’s the public part of the key.
Let’s establish this key as one that you can use to log in to your CS Linux account. There’s two ways to do this. The quick way, if your client machine has the ssh-copy-id command, is to do
ssh-copy-id -i yourPublicKeyFilename yourCSLogin@atria.cs.odu.edu
Alternatively, upload the public part of the key to your CS account on one of our Linux servers. On the CS Linux server, create a “~/.ssh” directory if you don’t have one:
mkdir ~/.ssh # if you don't already have this directory chmod 700 ~/.ssh
Then add the new key to your authorized key list:
touch authorized_keys cp -a authorized_keys authorized_keys.bak cat yourPublicKeyFilename >> authorized_keys
Now, back on your client machine, try connecting to a CS Linux server:
ssh -A yourCSLogin@atria.cs.odu.edu
You should be prompted for the passphrase for your new key.
Now, you may wonder what good that was. Every time you try to log in to a CS Linux machine, you will be prompted for that passphrase, which is probably much longer than your old password.
But usually, we don’t activate the private key for a one-shot login. Instead, we run a key agent on our client machine. We tell it to activate our private key (giving it the passphrase to prove that we are its owner). It then watches for subsequent ssh connection attempts and offers up the activated private key.
On your client machine:
eval $(ssh-agent) ssh-add ~/.ssh/yourPrivateKeyFilename
Then try giving the following commands from your client
ssh yourCSLogin@atria.cs.odu.edu date ssh yourCSLogin@atria.cs.odu.edu pwd ssh yourCSLogin@atria.cs.odu.edu ls ssh -A yourCSLogin@atria.cs.odu.edu
All of these should work with your being prompted at most once for your passphrase. The last one leaves you logged in to atria. From that session on atria, try logging in to sirius:
ssh sirius.cs.odu.edu
Again, you should find that you are able to do this without being prompted for your password or passphrase. The -A option in the earlier ssh command caused your agent’s credentials to be forwarded into your session on atria.
If you like this, you should look into the package keychain, which is a way to set up agents and acticate your keys upon logging in to your client. If you don’t care for it, restore your authorized_keys file in your CS account to its previous state (the .bak file). But keep those keys. We’ll use them later.
Fire up your installation of Eclipse.
Let’s let it know about your key. Go to Window ⇒ Preferences ⇒General ⇒Network Connections ⇒SSH2 ⇒General. Add your private key.
Install EGit, the Eclipse plugin for Git. (Help ⇒ Install new software...). After the installation, go to Window ⇒ Preferences ⇒ Team ⇒ Git and select a default folder in which you want your git repositories to be stored.
Take a moment and browse the EGit User Guide.
Open an ssh session on one of the CS Linux servers. Give the command
~zeil/Assignments/cs350/gitLab/step1
You will be given the URI of a git repository.
In Eclipse, go Window ⇒ Open perspective... and open the Git perspective. Move your mouse across the controls at the top of the Git repositories view and select “Clone a git repository…”. Enter the URI that you were given. Fill in your user name, but leave the password blank. Click Finish.
Look in your git repository folder. You should see that a new directory has been added. Look in that directory (use -a on Linux). You will see that it contains a .git directory, which is where the version control info is kept, and a directory for the real project.
In Eclipse, follow the usual procedure for creating a new Java project, but instead fo the default project location, select that project directory (the one alongside the .git directory, not the one that contains it).
Look around in the project. try compiling it. Don’t make any changes yet.
Back in your ssh session, give the command
~zeil/Assignments/cs350/gitLab/step2
This is simulating someone else on your team working on the same project. In Eclipse, right-click on your project and select Compare with... ⇒ HEAD revision. This compares against the most recent check-in to your local copy of the repository. Since you have not made any changes yet, you should not see much of anything, maybe a few new files created when you compiled.
Now try Compare with... ⇒branch, tag, … Select “Remote tracking” and then “master”. This compares against the remote repository, and you should be able to see that your mysterious teammate has checked in some changes.
In the synchronization view, find the file that has changed and double-click on it to open up the comparison editor.
Most of the version control commands are accessed by right-clicking on the project and looking under the Team menu item. Return to the Java perspective and use that to the changes from the remote repository.
Try making some simple changes, such as editing some of the comments in the source code.
From the Team menu item, commit your changes. As you examine the “commit” dialog, you will see that you have the option of doing a simple local commit or of doing a commit followed by an immediate push to the remote repository. Go ahead and push.
Back in your ssh session, give the command
~zeil/Assignments/cs350/gitLab/step3
In your Eclipse session, refactor the Pie.getBaseColor and Pie.setBaseColor functions, renaming them to getBackgroundColor and setBackgroundColor. By using the “refactor” menu, you get all calls to that function to be changed at the same time.
Now try to commit and push your changes. The commit should work, but the push fails because your mysterious teammate has already checked in some more changes to the project.
See if you can resolve this conflict and eventually commit and push a combination of your changes and those of your teammate. You will need to
The remote repository for this lab was stored in your Linux account as ~/.cs350gitlab.
To clean up after the lab (or to reset to the beginning if you want to start it over from the beginning), do
rm -rf ~/.cs350gitlab
While you still have those keys handy, now would be a good time to go to the course forge, log in to GitLab. Go to your Profile settings, select “SSH Keys”, and add your public key. This is how GitLab will know that your Eclipse IDE is allowed to work with your project. (Remember, you have already told Eclipse about the location of your private key. So, between the two of them, they have enough information to validate your credentials.)