SSH authorized keys for course class accounts

SSH authorized_keys for course class accounts

A system script runs every morning that checks the SSH authorized_keys files belonging to every course class account. It adds SSH public keys that are missing but which are authorised to be there, and deletes keys that are present but that are not authorised to be there.

It generally finds such keys in the CSE home directory of each person who should be given access.

Creating an SSH access key

Follow instructions at: SSH Key File Guide.

Who will 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?

People with CSE accounts are advised to place the SSH public key they wish to use for access in their CSE account (in ~/.ssh/authorized_keys). The system program can then find this key and add it to (course) accounts to which that person is supposed to have access. The program runs every morning.

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 the 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 which runs early each morning), then they should get someone with appropriate permissions to manually add their public key to the the course class account's authorized_keys file. This person will usually be the course administrator or lecturer.

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.


Course class accounts (eg: cs1011), have ssh authority files (eg: /home/cs1011/.ssh/authorized_keys) that contain public keys that come from those users that are considered to have authority to access (log in as) these class accounts. These authorized users will usually be course supervisors or lecturers, but may include other sets of users like tutors, and/or other interested and authorized individuals.

The problem (pre mid 2008)

Unfortunately, even when a particular user's association with the course ceases, and the user is no longer a member of the appropriate netgroup or UDB course class, the user's ssh public keys can remain in the class account's ssh authority file indefinitely, or at least until someone manually intervenes. Not managing these ssh authority files properly can lead to unauthorised or inappropriate access being granted to the class account, and a consequent loss of security.

The solution (post mid 2008)

As of mid 2008, a script runs daily which:
  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

Obviously, the script needs to be told the set of authorized users for each class account, and (perhaps less obviously) the set of files from which to source the authorised users' public keys. Two spec files are used to define both these sets of authorized users and public key sources for each class account:
  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

Both the global and the class account spec files have the following format: ('+' | '-') (user | '@' group) [ '[' expiry ']' ] {pub_key_source} [ '#' comment ] where:
Include the user or group.
Exclude the user or group.
The login name of the user to be included or excluded. In general, if a user is included (ie: with a '+') then an expiry date should also be specified (see expiry dates below for more details)
The UDB group whose members are to be included or excluded (eg: COMP1911_Lecturer). The group spec may include the string ${COURSE}. The value of ${COURSE} is expanded appropriately for each course class account processed, and allows the global spec file to specify general course related classes (eg: ${COURSE}_Supervisor).
The optional date after which the user or group is not to be included (with '+'), or excluded (with '-'). If given, 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).
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. By default (ie: 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/ .ssh/ .ssh/authorized_keys If the user is not a member of Employee then the default source files are: .ssh/ .ssh/ 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

The following are examples of additional lines added to cs1234's authorisation file: /home/cs1234/.ssh/ssh_authorized
  1. To include public keys of all tutors of this course (COMP1234): +@${COURSE}_Tutor or +@COMP1234_Tutor
  2. To (1) include jane's default ssh key files (until 10/4/2009), (2) exclude the transitive authorised_keys, and (3) include jane's additional key file (~jane/.ssh/special_file): +jane[10/4/2009] -jane .ssh/authorized_key + jane [10/4/2009] .ssh/.special_file
  3. To include just two of joe's key files: ~joe/.ssh/special_key and ~joe/other_keys, and none of any of joe's other key files till 10/4/2009. +joe[10apr2009] .ssh/joes_special_key other_keys
  4. 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: +cs1234 .ssh/external_users_keys

Transitive Authorization

The inclusion in a class account's SSH key file (~C/.ssh/authorized_keys) of the public keys from a user's public key source file: ~U/.ssh/authorized_keys allows for transitivity of authorization.

By default, transitive authorisation is only done for users who are members of the UDB class Employee.

For example:

If user A has SSH authority to become user B, then user A's SSH key(s) will appear in user B's authorized_keys file (~B/.ssh/authorized_keys).

If user B has authorization to SSH into the class account C, and if B is also a member of the UDB class Employee, then by default, the public keys found in B's authorized_keys file(~B/.ssh/authorized_keys) will be included in the authorized_keys file for the class account C (~C/.ssh/authorized_keys). In this way, by default, A is given transitive SSH authority to become the class account C.

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 transitivity is potentially a security risk, that it has been restricted to CSE Employees by default. Note that most tutors and class accounts are not members of the UDB class "Employee"

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


  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 generally 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
Last edited by zain 18/07/2018

Tags for this page:

SSH, class_accounts, authorized_keys