1 Special-Purpose SSH Keys

1.1 Creating Special-Purpose Key Pairs

Suppose that you wanted to allow someone else to try out a program that you had written and that is sitting somewhere in your account area. Let’s also suppose that you don’t want to make this program available to the entire world. For example, perhaps you are working on a programming assignment in one of my courses and you want me to take a look at your running program.

• You could, of course, tell me your login name and password, but that would be a bad idea unless you really, really trust me. (And why should you?)

• Based on what we have just seen, you could create an ssh key pair, add the public key to your authorized_keys file, give me the private key and its passphrase. Then, after I had tried your program out, you could simply remove that keu from ~/.ssh/authorized_keys to lock me back out.

  But that’s still way too trusting of you. During the time I had access to your program, I would have access to everything in your account. I would, even using the ssh keys, be logged in as you.

But we can actually adapt that second approach by limiting the key pair to running only a specific command or program when anyone uses it to log in.

1. Edit the public key that you created in the earlier steps.

   The key is typically written as a single long line ending in yourLoginName@_machineName_, reflecting where you created the key. To the front of that line, add command="/usr/bin/env",no-port-forwarding and a blank space, right in front of the “ssh-rsa”.

   (If you aren’t familiar with te env command in Linux, run it to see what it does.)

2. Add that edited public key to your authorized keys list on the server as you did earlier.

3. You should still have a key agent running on your client. If not, restart it and add your private key.

   Now try logging in via that key by giving the following commands on the client:

   ssh yourCSLogin@atria.cs.odu.edu
   ssh yourCSLogin@atria.cs.odu.edu pwd
   

   Notice that, whether you give a specific command for ssh to execute on the remote server or omit it, trying for a normal login session, what actually happens is that you are logged in to your account, the env command is run, and then you are logged out.

So, to return to our earlier example, if you were working on a programming assignment in one of my courses and you want me to take a look at your running program, you could create a special-purpose key pair to run that program (and do nothing else), and then give me the private key and passphrase, knowing that I would be limited to using your account for that single purpose.

1.2 Playing with Fire: Password-Free Key Pairs

Now we are going to do something a bit dangerous.

1. Shut down the key agent on your client machine with the command

   ssh-agent -k

2. Create a new key pair, giving them a different name from the ones you set up earlier.

   This time, however, when prompted for a pass phrase, just hit Enter to create a key pair without a pass phrase.

3. Now, adding that key to your authorized key list would be risky, because anyone who got a copy of the private key would be able to log into your account using no passphrase at all.

   So, to keep this safe, immediately edit that public key. This time add

   command="pwd",no-port-forwarding
   

   to the beginning of the public key.

4. Add that edited public key to your authorized key list on the server.

5. On the client, give the command

   ssh -l yourCSLoginName -i path/To/Your/New/Private/Key atria.cs.odu.edu

   You should see that the command is executed without your being prompted for a password or pass phrase.

When you have succeeded in completing these steps, you can remove the keys you have added to your ~/.ssh/authorized_keys file on the server.

2 Background – Serving Web Pages

Anyone with a CS account can publish web pages on the CS web server. the mechanism for doing this is very straightforward:

Any file stored on the Linux file system at

~_loginName_/public_html/_whatever_

will appear on the web server at the URL

http://www.cs.odu.edu/~_loginName_/_whatever_

To see this in action (if you have not previously taken advantage of this service), create the directory ~/public_html if you do not already have one.

Inside there, create a file named firstPage.html containing

<html>
  <head>
      <title>First page</title>
  </head>
  <body>
    <p>
	   This is page 1.  There is
	   no page 2.
	</p>
  </body>
</html>

Then direct a web browser to http://www.cs.odu.edu/~_yourLoginName_/firstPage.html and you should see your page.

If not, look at your permissions. The web server does not run under your account. But it needs to be able to access your public_html directory. That means that you need to carefully open up the correct path to your web content without leaving your entire account wide open.

• Your login directory must provide execute permission to the world. (“Execute” permission on a directory means that someone who knows the name of a file within the directory can get to that file. However, Execute permission on a directory does not allow someone else to list the contents of your directory to see what’s in there.)

  chmod 711 ~
  

• Similarly, the web server will need to get to files within your public_html directory (and any sub directories within it):

  chmod 611 ~/public_html

• The actual web content within your public_html directory (and any sub-directories of it) must be readable by the web server:

  find ~/public_html/* -type d -exec chmod 755 {} \;
  find ~/public_html/* -type f -exec chmod 644 {} \;
  

3 Copying (synchronizing) files

Web sites generally consist of multiple files, including HTML, graphics and style sheets. These are often arranged into a hierarchy of directories.

If you and a group of team mates want to copy files from each of your own work areas into a shared directory within your public_html directory, how are you going to do it.

• The basic cp command will copy files, including entire directory structures (with the -r option). But your teammates would only be able to do this if their work area is on the same machine and if you made the directories writeable by everyone in the world, which is not a good idea unless you want your website trashed by every wannabe hacker and script-kiddie on the network.

• ftp, sftp, and scp would allow for more controlled access.

  • Because sftp and scp are really variations on ssh, we might expect that we could use ssh keys to give our team members access to the web site directories.

    That is indeed our goal in this task, but…

  • sftp and scp work only one file at a time, making it hard to keep multiple nested directories in sync.

    It could be done by using packing the whole website into a .zip or other archive format, trasnferring the archive file in one step with sftp or scp, and then issuing an ssh command to unpack the archive on the remote server.

    But that’s kind of messy, and many updates to a website will only affect one or two files at a time. Transferring the whole thing on every update could be excessively slow.

  • If we’re going to use ssh keys to give our teammates access to the directory, we’d like to limit that access to just that directory and not allow them to run arbitrary commands under your login. That would seem to be a job for the command= feature of ssh public keys. But it’s not clear what copmmand to use to limit people to just copying file and, expecially, to copying file to/from a specific directory.

3.1 rsync

4 Setting Up a Tream Website

1. Set up a website directory for the team. For the same of this example, I’m going to set up a site that would be accessed as http://www.cs.odu.edu/~zeil/projectReports/.

   The web pages at URLs http://www.cs.odu.edu/~zeil/… are located in directory /home/zeil/public_html/…. Of course, you would need to replace my login name zeil by your own to set up your own website.

   So, in the directory /home/zeil/public_html, I would create a directory projectReports/. I would set the permissions to 711, so that I have full access (7) and the webserver can navigate to specified directories (1).

   • Even though I’m setting this up for my team, they don’t need write access to the directory because we’re going to set things up so that when depositing files, they are logged in as me.

2. In that directory, add a web page titled “index.html” that displays simply the phrase “Project Reports”.

   (An index.html file displays by default if someone browses to the directory without naming a specific file. By providing an index.html file, you not only set up a convenient starting point for a website, you also prevent people from using their web browser to simply list all of the files in your directory.)

3. Set up a passphrase-free pair of ssh keys. Add the command=rrsync… limitation to the front of the public key:

command="/home/zeil/bin/rrsync /home/zeil/public_html/projectReports/",no-port-forwarding,no-agent-forwarding…rest of public key…

Add that restricted public key to your `authorized_keys` file.

1. You can now distribute the private half of that key to your teammates, knowing that the only use they can make of it is to add and update files in the website.