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 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.

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 File 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

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.
user
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)
@group
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).
[expiry]
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).
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. 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/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

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

If the user U's public keys from ~U/.ssh/id_dsa.pub and/or ~U/.ssh/id_rsa.pub are included in the class account C's authorized key file ~C/.ssh/authorized_keys, then U can be said to have "Direct authorization" to access C.

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

Examples:
  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
Last edited by zain 26/07/2018

Tags for this page:

SSH, class_accounts, authorized_keys