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.

Creating an SSH access key

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

1. A member of the UDB classes: $COURSE\_Supervisor or $COURSE\_Lecturer. Membership of these UDB classes is controlled by the teaching allocation files (described in more detail in the article on Teaching administration).
2. A member of a UDB class 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);

Which keys get applied to course accounts?

• From: The user's public SSH keys stored in their ssh directory: ~U/.ssh/)
• **To:**The course account's authorized keys file ~C/.ssh/authorized\_keys.
• By default, keys are usually only taken from either of the SSH public key files ~U/.ssh/id\_ed25519.pub or ~U/.ssh/id\_rsa.pub.
• In addition, authorised users who are also members of the UDB class Employee will also have their public keys stored in ~U/.ssh/authorized\_keys copied into the course account's authorized keys file.

Details

Course class accounts (eg: cs1011), have ssh authority files (/home/cs1011/.ssh/authorized\_keys) that contain public keys that come from those users that are granted access to 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, when a user's association with a particular course ceases, and the user was no longer a member of the appropriate netgroup or UDB course class, the user's ssh public keys would usually remain in the class account's ssh authority file until someone remembered to remove their key manually. Not managing these course class ssh authority files properly would 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 was written which runs daily, and 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.

Note:

1. The script only regenerates authorized_keys for those class accounts that have a ~/.ssh/ directory.
2. Email is sent whenever there is a change to the class account authorization file. Such email includes:
   • The name of the user whose keys were added or removed (if known).
   • The actual keys that were added or removed.
   • The name of the file that was the source of the key (appended to the end of each key).
3. Only non-empty user SSH keys that do not start with command= are copied into the class account's authorized_keys file. This is intended to exclude restricted SSH keys of the sort generated by gitosis and which are used to allow users restricted access to each other's git repositories. user4. Early in 2025, we discovered that some user's public keys may have been compromised. Since then, user public keys will only be included in course class authorized_keys files if and only if:
   1. The public key comes from a user SSH file that has been modified or created after this compromised date.
   2. The public key does not match any of the keys in a blacklist of potentially compromised keysUsers and class accounts are emailed if keys have been excluded for either of these two reasons.

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/authority to add or remove any user or set of users to/from the default authorised set. For instance, the course authority might want to confer course class access to all course tutors (with +@${COURSE}_Tutor).

• The global spec file is always read before the class spec file.
• It is expected that in most cases the global spec file will suffice, and that course classes will not need to create their own spec file.
• Individual users (and their source files) are added to or removed from the list of authorized users (and their source files) in the order in which they are read from the two spec files.

Spec File format

Both the global and the class account spec files have the following format: [class_pattern] ('+' | '-') (user | '@' group) [ '[' expiry ']' ] {prefix=string} {pub_key_source} [ '#' comment ] where:

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

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

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

• If the user is a member of Employee then the default source files are: .ssh/id_ed25519.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_ed25519.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 the user U's public keys from ~U/.ssh/id\_ed25519.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.

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

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