SSH authorized_keys for course class accounts

Summary

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

See the SSH Key File Guide.

Giving a user SSH access to a course class account

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

A member of $COURSE_Supervisor or $COURSE_Lecturer. Membership of these system classes is controlled by the teaching allocation files (described in more detail in the article on Teaching administration).
A member of a system class explicitly specified in the file: /home/$courseclass/.ssh/ssh_authorized (described in the section onSpec File format below);
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 when it runs early the next 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.

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

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.
Sends email to the class account if user keys are added to, or removed from, the class account's authorization file.
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:

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

If a group is specified, and an expiry date is not given, then the group members are no longer included (or excluded) when their respective group membership expires.

If a user is explicitly nominated, and an expiry date is not given, then that user is no longer included (or excluded) when their account expires. Users included (with a '+') without an expiry date will cause a warning email to be sent to the class account no more than once a week.
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.

Examples


	+@${COURSE}_Tutor    # include keys of members of the tutor course class.
        +janedoe[10/4/2009]  # include jane's default ssh key files till 10/4/2009
	-janedoe .ssh/authorized_keys   # exclude jane's authorized_keys file
	+ janedoe [10/4/2009] .ssh/.special_file # include jane's special_file
	+joeblo[10apr2009] .ssh/joes_special_key_file another_file # include joe's key files till 10/4/2009
	# note that joe's default ssh key files are not included.

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 a 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 the class account's ssh_authorized file.

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

Note: user's ssh keys starting with "command=..."

cse taggi

SSH authorized keys for course class accounts