SSH Key Access"> Course Account SSH Key Access

We use ssh and public keys to provide access to course accounts.

This is background information on using SSH public keys to authenticate as a course account. Looking at that document first is recommended.

CSCF has deployed an automated tool to propagate ssh keys to course accounts from home directories in the student region (i.e. one of the linux.student.cs.uwaterloo.ca systems). Authorized users of a course account will be able to ssh and scp from their preferred workstation into the course account, after a one-time key copy to their own student-environment account. An automated check for new keys happens once an hour.

For answers to questions about this process, contact DanielAllen.

Latest Updates

As of February, 2011, everything works the same on Linux and Solaris hosts: the login mechanism now includes recognition of your original username, as it previously did with rsh, so you do not need to supply your username after logging into the course account on student.cs.

As of October, 2010, the key-copier will now check your $HOME/.ssh/authorized_keys file in the student region, in addition to copying public-keys in $HOME/.ssh - to allow you to record keys for multiple workstations. See the second FAQ entry below if you have multiple keys to be copied.

Setup Instructions for Course Accounts Users

• If you do not know your CS-TEACHING password (for linux.student.cs.uwaterloo.ca), set it at: https://www.student.cs.uwaterloo.ca/password/.

• Create a ssh key on the preferred machine(s) you usually work from, whether inside or outside UW, and copy the public key file to linux.student.cs.uwaterloo.ca.
• If you have no other suitable computing environment, you can set up your ssh key directly on linux.student.cs.uwaterloo,.ca. Log in (see above if you need to set/reset the password) and issue the command: ssh-keygen.
  • Step-by-step instructions are available for Linux and Macintosh and for Windows.
• If this is a new user for the course account, notify the course manager or your CSCF course contact to have the .rhosts file updated.
• If this is a current user for the course account, the automated key-propagating tool will copy the key within an hour.
• You may now log in from your preferred machine to the course account using the command: ssh course-name@linux.student.cs.uwaterloo.ca

Questions and Answers

Q: I've generated a key. Can I get more detail about copying the key to linux.student.cs.uwaterloo.ca?

From Unix/Linux, try ssh-copy-id yourlogin@linux.student.cs.uwaterloo.ca and it should be copied over correctly.

From any OS: use copy and paste:

• From Mac/Unix/Linux, look for your key in ~/.ssh/id-dsa.pub
• From Windows, see here for details about finding the key's location.
• Select and copy the entire key. It will look something like:

        ssh-dss AAAAB3NzaC1kc3MAAACBAKAtgLEWHkwKJOjVUVvBEjpYE172mcoJkMyuX6kHSY7ZayF760+0
        v22LSI6ATyZ5EcY0IZzG+A0er4Ns0puH5eWdQ6nBxnvnwkZRiUfbDCIOauyUdDZNdCTRk7+dhr3Cdpwp
        [5 lines deleted]
        Yjm0P02TeCMO7KTezbVKSFrEeg== daniel@zot.local

• It must have no carriage-returns in it. (the above is reformatted for display).
• log into yourlogin@linux.student.cs.uwaterloo.ca via your preferred means (ssh or rlogin)
• create the .ssh subdirectory if it doesn't exist:
  • mkdir ~/.ssh
• paste the key:
  • cat >> ~/.ssh/id-dsa.pub [carriage-return] [paste the key] [ctrl-C]
• It must be pasted all on one line. Use an editor to remove any carriage-returns.

If you already have a different key on the student-region host, see the second part of the following question.

Q: What if I use more than one home workstation/machine to access course accounts? Which part of this do I repeat?

You have two choices:

• create one key, which you will copy to the additional workstations. You must copy both halves ( id_dsa and id_dsa.pub) to the other machines' ~/.ssh directory (creating the directory if necessary). Ssh from both machines will now identify to other machines with the same identity. This is the simpler approach, and is acceptable if each machine you work from has equivalent levels of security / risk of someone stealing the private key.

If one is less trusted and/or you want to keep the private keys separate, you can:

• create different keys for each machine.
• Then, copy and paste the each key to the end of the following file on linux.student.cs.uwaterloo.ca: $HOME/.ssh/authorized_keys
  • Each key must go on a separate line of the file. Your authorized_keys will look something like this:

        % cat ~/.ssh/authorized_keys
        ssh-dss AAAAB3NzaC1kc3MAAACBAKAtgLEWHkwKJOjVUVvBEjpYE172mcoJkMyuX6kHSY7ZayF760+0
        v22LSI6ATyZ5EcY0IZzG+A0er4Ns0puH5eWdQ6nBxnvnwkZRiUfbDCIOauyUdDZNdCTRk7+dhr3Cdpwp
        [5 lines deleted]
        Yjm0P02TeCMO7KTezbVKSFrEeg== daniel@zot.local
        ssh-dss AAAAB3NzaC1kc3MAAACBAM/a0SBDrtC5iDXRKTrkFK57+h6QyH3WeTGKLhBSF0mkxwuVE6L2
        [5 lines deleted]
        5h/IxIId5eOphnNSOHH+oVpjs1k= drallen@scsmac21.cs.uwaterloo.ca

Note that each key is copied as one line, which you can check by running word-count on the file:

        % wc -l ~/.ssh/authorized_keys
               2 /u1/yourusername/.ssh/authorized_keys

The number in the response ("2" above) must match the number of keys you copied; otherwise, the key was copied with embedded carriage-returns which must be edited out.

Also note that all core-region servers (cpu1XX.cs) count as "one machine" and separately all of student-region counts as "one machine", because your home directory is shared among regional machines. If you work on cpu102.cs and cpu104.cs, you only have one key to copy to linux.student.cs.uwaterloo.ca.

Q: If I generate a key on my home machine, is this an additional security risk? If someone steals my private key, can they access my home machine?

No, the relationship with keys is not symmetric: unless you run ssh daemon on your home machine, and add the key to your home machine's $HOME/.ssh/authorized_keys file, there is no additional risk to your home machine.

If your private key is stolen, the public key must be removed from authorized_keys on any host it is used on, because it does allow access to those hosts.

If you use a passphrase with your ssh key you have additional assurance that if your private key is stolen, you can replace it before your accounts are broken into.

Q: Is there a way around re-typing your passphrase every time you use the public key?

Yes. See this bit about caching your passphrase.

Q: Specifically which locations for keys are checked by the automated system?

Keys copied from the following standard key locations in the user's .ssh directory: identity.pub, id_rsa.pub, id_dsa.pub, authorized_keys, and authorized_keys2. If you happen to be working with a "course testing account" (ending in -t or t), only identity.pub, id_rsa.pub, and id_dsa.pub are checked, and only for the course-account corresponding to the testing-account's course-name.

Q: What does the automated key copier do?

• The key copier first checks the .rhosts and .shosts files for each course-account and identifies all users. It then checks for the existence of updated keys in the home directory of each user. If the user's key information is more recent than the last automated update, it will copy the current set of keys to the course account.
• Updates are copied to the course account's .ssh/.authorized_keys file, which has two sections; a manually-edited section and an auto-updated section. The manually-edited section is more authoritative and is not touched by the automated system. The sections are separated by an comment which warns that changes below that point in the file will be overwritten.

Q: Is there more detailed information about how to use the ssh command?

Yes; for detailed information, see manpages on the student-region hosts: man ssh for logging in, and man scp for copying files (or PuTTY and WinSCP on Windows).

CSCF Administration

In theory, we could run this tool manually whenever edit_rhosts is run, in addition to the automated runs; in practice, the 1-hr delay before key copies is probably fine.

If there is need to manually run the tool, as root on cron.student.cs.uwaterloo.ca run: /software/local_cron.student.cs.uwaterloo.ca/bin/pull-ssh-keys -f $COURSE_ACCOUNT_NAME

Where -f forces an update for the given course account $COURSE_ACCOUNT_NAME.

If there is need to be sure a user's keys are updated for all courses they are involved with, you can signal that their key information has changed. From any student-region host, touch $USER/.ssh/authorized_keys and the next automated run will update all known courses for that user.

More Detail on Implementation

The scripts run on a host which is in the student region; currently cron.student.cs.uwaterloo.ca. It could run on other hosts, but we chose an unloaded machine to lower likelihood of high loads.

Scripts are located in the xhier package local_cron.student.cs.uwaterloo.ca:

• export/crontab has two entries:
  • 0332h: egrep 'Teaching-(SE|CS)' /software/accounts/data/users |awk -F':' '{print $1}' > /software/local_cron.student.cs.uwaterloo.ca/data/group-accounts
  • every hour on the 11th minute: pipe the preceding data file to /software/local_cron.student.cs.uwaterloo.ca/bin/pull-ssh-keys
• bin/pull-ssh-keys
  • perl script plus two perl libraries residing in subdirs Text and Algorithm
• data/group-accounts - generated file, see crontab entry above

As described in ST#64298, there is a patch to the sshd package to make this process work smoothly. The patch for xhiered Solaris is maintained by Jeff Voskamp in IST. The patch for linux.student.cs.uwaterloo.ca (currently ubuntu 9.10 LTS) is maintained by Daniel Allen. The openssh maintainers have approved the patch's inclusion (in principle) in the official release, which may happen in 2011; at some later point ubuntu should pick up the version. Until then, CSCF will maintain a patched sshd on linux.

The patch's purpose is to avoid a security hole with the "PermitUserEnvironment" sshd option, as described in the above ST. The patched format for PermitUserEnvironment allows our hosts to include the following sshd_config stanza:

PermitUserEnvironment REMOTEUSER

The automatically-generated authorized_keys data for each course-account will include REMOTEUSER via the following format:

$ cat .ssh/authorized_keys
environment="REMOTEUSER=drallen" ssh-dss AAAAB[...]+js1k= comment-such-as-user@host=

sshd on the linux.student.cs.uwaterloo.ca host will include the REMOTEUSER variable as the user logs in as the course-account; which is used by our default course-account login script to cd the proper course-account user directory. Without REMOTEUSER set, each login will involve a prompt "User Id?" to which the user should fill in their regular user-id.

The automatically generated authorized_keys data also includes a copy of the key without the REMOTEUSER variable, so if the connection happens without the patched sshd, authentication by public key will still occur.

-- DanielAllen - 07 Jan 2009