= SSH Security Policy =

[This is a proposed policy, not yet implemented. Due to security considerations the discussion is not public.]

The following policies guide secure shell access to our servers:

 * All root passwords have 30 character randomly generated passwords shared in encrypted form with a limited number of May First/People Link root administrators. May First/People Link root administrators store these passwords in encrypted files on encrypted disks.

 * Key-based root ssh access is enabled on all servers. ssh will be configured to prevent password-based root access. Note: This feature requires running ssh from Lenny which currently (2008-03-23) is only available in Debian Testing (Lenny). Rationale: There are arguments for turning off root ssh access on servers that allow password-based authentication to avoid dictionary attacks. However, with an upgrade to a version of ssh that enables us to allow password-based authentication for members while requiring key-based only authentication for root, we can avoid this weakness. In addition, with randomly generated 30 character passwords, the chances of cracking them with a dictionary-based approach comparable if not harder than cracking an ssh public key to gain access. And, our public keys are [wiki:mfpl_admin_public_ssh_keys published].

 * All MFPL root administrators secure their private key with a password and only save them non-shared computers with encrypted disks.

 * Root access is not available via sudo. Root is only available via ssh as root or by ssh'ing into the [wiki:telehouse_serial_access serial console server] and logging in with the username and password. Rationale: sudo is useful because it allows users to work as a non-privileged user and execute select commands as root. That cuts down on mistakes that can have disastrous consequences. However, it also makes each server only as secure as the non-privileged user. 

 * All ssh keys used for root access are minimally 2048 bits in length

 * May First/People Link conducts an annual audit to check in with all users with root access and ensure that they these policies are being followed and review that all users with root access know they have root access, still want root access, and it makes sense for the organization for them to have root access.