The script copies the keys from the CSE home directories of each person who is authorised to be given access.

Creating an SSH access key

Follow instructions at: SSH Key Guide.

Who is authorised to get SSH access to a course account?

A CSE user is authorised to have SSH access to the course class account: $courseclass, servicing the course: $COURSE, if the CSE user is either:

1. A member of the netgroups $COURSE_Supervisor or $COURSE_Lecturer. Membership of these netgroups is controlled by the teaching allocation files (described in more detail in the article on Teaching administration).
2. A member of a system netgroup explicitly specified in the file: /home/$courseclass/.ssh/ssh_authorized (described below);
3. Explicitly named in the file: /home/$courseclass/.ssh/ssh_authorized; (described below);

How do keys get applied to course accounts?

Early each morning, a system script copies the public SSH keys from the ssh directories (~U/.ssh/) of those users U authorised to access the course accounts, into the course account's authorized keys file ~C/.ssh/authorized_keys. Authorised users U are advised to place their SSH public keys into either ~U/.ssh/id_dsa.pub or ~U.ssh/id_rsa.pub. Authorised users who are members of the UDB class Employee will also have the public keys stored in ~U/.ssh/authorized_keys copied into the course account's authorized keys file.

A non-CSE user may gain SSH authorisation to a course class account, by having their public key stored in a file in a CSE user's account (usually the course class account itself), and having this file explicitly named in the file: /home/$courseclass/.ssh/ssh_authorized; (described below);

If a user does not want to wait for their public key to be automatically added to the course class account's authorized_file by the system script that runs each morning, then they can get SS to manually run the system script at any time instead. Alternatively they could get someone with appropriate permissions (usually the course administrator or lecturer) to manually add their public key to the the course class account's authorized_keys file, but they will need to make sure that their public keys are also stored in the correct place in their ssh directory, or the system script will remove the manually added keys the next time it runs.

Email will be sent to both the class account and to the user whenever the system script adds or deletes public keys from the course class account's authorized_keys file.

Background

The problem (pre mid 2008)

The solution (post mid 2008)

1. Automatically regenerates the .ssh/authorized_keys file from the public key entries belonging to all the users who have authorised access to the class account.
2. Sends email to the class account if user keys are added to, or removed from, the class account's authorization file.
3. Sends email to all users whose keys are added to, or removed from, any class account authorization file.

Spec files

1. The global spec file: /home/sms/lib/ssh_authorized.default. This spec file defines the default set of users that have authority to access any class account and includes the lines: +@${COURSE}_Supervisor +@${COURSE}_Lecturer (See spec file format below for a description of what this means)
2. The class account spec file: /home/${courseclass}/.ssh/ssh_authorized. This spec file allows the course account to add or remove any user or set of users to/from the default authorised set.

Spec File format

[class_pattern]

If a spec line starts with this optional class_pattern, then the pattern is matched against the name of the class account whose ssh keys are being created.

• The pattern is in the form of an extended regular expression (eregexp) as used in perl;
• If the pattern does not match the class account name, then this specification line is ignored;
• The eregexp may include the use of braces ( '(' and ')' ) to capture matching substrings within the class account's name. These matching substrings can then be referred to using '$1', '$2', etc., in the user or group that follows in the same specification line.

Although class_patterns can be used in the class account spec file, it is really only useful when it is used in the global spec file, where the class pattern can be used to selectively apply the spec line to only those class accounts matching the class pattern.

Default:If a spec line does not start with a class_pattern, then the spec line applies to all the class accounts to which this spec file applies.

+

Include the user or group.

-

Exclude the user or group.

user

The login name of the user to be included or excluded. Note:

• In general, if a class account's spec file includes a specific user (with a '+'), then an expiry date should also be specified (see expiry dates below for more details).
• The login name may include references to:
  • ${COURSE} - which is replaced by the appropriate course class associated with the course account; or
  • ${1}, ${2}, etc - which is replaced by the substrings matching the n'th matching pair of braces in the class_pattern eregexp.

@group

The UDB group whose members are to be included or excluded (eg: COMP1911_Lecturer). Note:
The group name may include references to:

• ${COURSE} - which is replaced by the appropriate course class associated with the course account whose ssh keys are being created. This allows the global spec file to specify general course related UDB classes (eg: ${COURSE}_Supervisor) related to each course class. ; or
• ${1}, ${2}, etc - which is replaced by the substrings matching the n'th matching pair of braces in the class_pattern eregexp.

[expiry]

The optional date up to which the user's or group's ssh keys are to be included (with '+'), or excluded (with '-').

The expiry date must be enclosed in square brackets, and may be specified as either: [dd/mm/yyyy] or [ddMMMyyyy] where dd, mm and yyyy are the numeric date, month and year, and MMM is the alphabetic month (eg: jul).

Default:If no expiry is specified, then the user or group is included or excluded in perpetuity. However:

• If a group is included in perpetuity then a group member is no longer included when their respective group membership expires;
• If a user is included in perpetuity, then that user is no longer included when their account expires. Users included in perpetuity who have expired will cause a warning email to be sent to the class account no more than once a week. This is intended to encourage the class account administrator to clean up the class account's ssh spec file.

{prefix=string}

These define the strings to prepend to the SSH keys taken from user or members of @group. This is particularly useful for inserting so called "command" prefixes, or for including limiting ssh options. Note:

• None of the specified prefix strings can themselves contain any spaces; If the final prefix string appearing before each SSH key needs to include spaces, then you should specify as many prefix strings on the same spec line as are separated by spaces. Each prefix string will be printed out in the order specified with a single space separator.
• A single space will always separate the prefix string(s) from the SSH key in the final SSH authorized_keys file

See Spec File Examples below.

{pub_key_source}

This is the relative pathname of the file(s), rooted at each user's home directory, that contain the public keys to be included in the class account's .ssh/authorized_keys file.

Default:If no files are explicitly specified, the source files to be included (or excluded) will depend upon the classification of the user:

• If the user is a member of Employee then the default source files are: .ssh/id_dsa.pub .ssh/id_rsa.pub .ssh/authorized_keys
• If the user is not a member of Employee then the default source files are: .ssh/id_dsa.pub .ssh/id_rsa.pub

For the rationale behind including .ssh/authorised_keys, see the section onTransitive Authorization below.

#

Optional comments start with a #, extend to the end of line, and are ignored. Blank lines are also ignored.

Spec File Examples

1. In this example, assume:
   1. The course is: COMP1234
   2. The course class is: cs1234
   3. The authorisation file is: /home/cs1234/.ssh/ssh_authorized
   
   
   • To include public keys of all tutors of this course, insert the following lines in the authorisation file: +@${COURSE}_Tutor or +@COMP1234_Tutor
   • Insert the following lines in the authorisation file to:
     1. Include jane's default ssh key files (until 10/4/2009)
     2. Exclude transitive authorisation of jane's authorized_keys
     3. Include jane's additional key file (~jane/.ssh/special_file)
     +jane[10/4/2009] -jane .ssh/authorized_keys + jane [10/4/2009] .ssh/.special_file
   • To include only two of joe's key files: ~joe/.ssh/special_key and ~joe/other_keys, and none of joe's other key files, up until 10/4/2009, insert the following line in the authorisation file:
     +joe[10apr2009] .ssh/joes_special_key other_keys
   • To include various public keys of people who do not actually have CSE accounts, place their public keys into ~cs1234/.ssh/external_user_keys, and include the following line in the authorisation file: +cs1234 .ssh/external_users_keys
2. The following example shows the use of a class_pattern, substring matches, and the prefix string in the global spec file. (\w+)exam +${1}vx prefix=command="/home/virtualexam/bin/vxstart",no-agent-forwarding,no-port-forwarding,no-pty .ssh/id_rsa_exam.pub Note:
   • The class_pattern (\w+)exam matches any course class account ending with 'exam' (eg: dp1091exam). Note that any course class account not ending with exam will not have this spec line applied to them.
   • The course class account (eg: dp1091exam) has an SSH key copied into its authorized_keys file from the the user named ${1}vx (eg: dp1091vx) from their public SSH file .ssh/id_rsa_exam.pub (eg: /home/dp1091vx/.ssh/id_rsa_exam.pub). Note that nothing is copied if neither the user nor the file exists.
   • The SSH key from the public SSH file is copied into the course class' authorized_keys file (eg: /home/dp1091exam/.ssh/authorized_keys) with the string command="/home/virtualexam/bin/vxstart",no-agent-forwarding,no-port-forwarding,no-pty appended at the start of each key found. Note: a single space will always be inserted between the final prefix string, and the actual SSH key.

Transitive Authorization

If however, the public keys from U's authorized key file ~U/.ssh/authorized_keys are also included in the C's authorized key file, then all other users O who have direct authorization to access U, and whose public keys are in U's authorized key file, can be said to have "transitive authorization" to access C.

Note that by default, U's authorized key file is only ever copied into the course class C's authorized key file if:

• U has direct authorization to access the course class C; and
• U is a member of the UDB class Employee.

This default transitivity is specifically intended to make it easy for Employees at CSE, who are authorized to SSH into a class account, to pass onto the class account the public keys originating from their accounts outside of CSE (typically generated either on their private computer(s) at home, or on their personal laptop). This presumes that such users will include their public keys from their non-CSE accounts in their .ssh/authorized_keys file at CSE, primarily so that they can login to CSE remotely as themselves.

It is because this automatic transitive authorization is potentially a security risk, that by default, the copying of the authorized_keys file to the course class's authorized_keys file has been restricted to CSE Employees. Note this will prevent the authorized_keys file belonging to most tutors and class accounts from being copied to class accounts as most tutors and class accounts are not members of the UDB class "Employee"

If desired, it is possible to explicitly include the copying of non-employee's authorized_keys files, or to explicitly exclude the copying of employee's authorized_keys files, by adding entries in either the global spec file, or in the local (class account's) ssh_authorized spec file.

Modifying default transitive authorization

1. In 2018 s2, the global spec file was changed to allow transitive authorization for all course lecturers, whether or not they were members of Employee, by adding the following line to the global spec file: +@${COURSE}_Lecturer .ssh/authorized_keys
2. In the following example:
   • userE is a member of Employee to whom we want to confer SSH access, but not transitive access.
   • We want to confer transitive SSH access to Tutors (who are usually NOT members of the UDB class Employee).
   ~C/.ssh/ssh_authorized: +userE # include default employee SSH key source files -userE .ssh/authorized_keys # remove transitive access +@${COURSE}_Tutor # include default non-employee SSH_key source files +@${COURSE}_Tutor .ssh/authorized_keys # include transitive access