PERT SSH Procedures

Introduction

In the course of the investigation of a performance issue, it is often extremely useful for a PERT Case Manager (CM) to be able to log in on equipment at a PERT customer's premises in order to run tests and investigate end system configuration.

This document suggests two protocols: One between the PERT and a customer for requesting, granting, and revoking authorisation for login access, and one between the PERT's Case Managers for passing authentication information between each other.

Basic Idea

Use SSH with Public-Key Authentication

For many types of end-user equipment including all Unix-based machines, SSH (Secure Shell) is the ideal mechanism for a PERT Case Manager to remotely log in to customer equipment. SSH provides many authentication mechanisms through which logins can be authorised. The most widely used authentication mechanisms are based on passwords and public keys, respectively. Because password authentication is vulnerable to guessing attacks, this type of authentication is often administratively disabled. Therefore, public key authentication is probably the best method to use.

One SSH Identity per Set of Hosts

There are various possible granularities of the private/public key identities to be used: at one extreme, a single identity could be shared by all PERT CMs, at the other extreme, each PERT CM could use its individual identity. We propose a middle ground: An identity that is specific to a set of customer machines (typically as part of the same PERT case) and shared between PERT CMs as they work on the relevant case(s).

Establishing Access Permission

When a PERT CM decides that login access to customer hosts would be helpful, he or she should generate a new identity for use with the current case. In the OpenSSH implementation, such an identity can be generated like this:

ssh-keygen -t dsa -b 1024 -f ~/.ssh/pert-deisa

This will create a private/public key pair and store it in the user's .ssh/pert-deisa and .ssh/pert-deisa.pub files. The generation process will ask for a passphrase to protect the private-key file. The user should use a personal hard-to-guess passphrase to make this protection effective. This passphrase will not be shared with others.

When asking a PERT customer to authorise login, the contents of the public-key file (.ssh/pert-deisa in the example) must be provided to the customer. The customer should create a test account with appropriate privileges, and grant SSH login authorisation by putting the public key into the account's .ssh/authorized_keys file. The home directory, .ssh directory, and .ssh/authorized_keys file must be owned by the test user, and must not be writable by other users. In addition, the .ssh/authorized_keys file should be read-protected from other users to minimise the risk of disclosure.

After the customer reports back to the PERT CM, the CM will verify that login access works as desired, using the new identity for authorisation. Assuming that the customer created the test account with the name pert:

ssh -i ~/.ssh/pert-deisa -l pert testhost.deisa.org

Alternatively, the PERT CM can use the SSH Authentication Agent (ssh-agent) to store the new identity:

ssh-add ~/.ssh/pert-deisa
ssh -l pert testhost.deisa.org

This avoids having to type the passphrase for every login.

Pass Identity from CM to CM

As part of the Case Manager hand-off process, the outgoing case manager should pass the active SSH identities to the next CM. Only the private key file has to be sent, because the public key can be regenerated from the private key.

The outgoing CM must unlock the private key with her passphrase before sending it to the incoming CM. This can be done by copying the private-key file and changing the passphrase using ssh-keygen -p:

cp -p .ssh/pert-deisa .ssh/pert-deisa-export
ssh-keygen -p -N '' -f ~/.ssh/pert-deisa-export

The ~/.ssh/pert-deisa-export file now contains the private key without passphrase protection. It should be sent to the incoming CM through a secure channel, e.g. encrypted using PGP, and then immediately be deleted. Upon receipt, the incoming CM should store the private-key file and protect it immediately with her personal passphrase (using ssh-keygen -p -f.

Revoke Access

When a PERT CM decides that access to the customer's system(s) is no longer needed, he or she should inform the customer of that fact. The customer will then lock the PERT account(s), either by deleting them completely, or by deactivating them temporarily, to make it easier to re-establish access in case it is needed for another PERT case.

Open Issues

Would a single PERT SSH identity be sufficient?

A single SSH identity for the PERT would be easier to manage, but it would be hard to prevent it from proliferating. This could jeopardise the willingness of PERT customers (and their systems administrators/security experts) to grant login access to the PERT CM.

What about systems that don't support SSH?

While SSH servers are installed on the majority of Unix/Linux machines today, it is less common on other systems such as Windows computers. We should investigate whether a usable SSH server for Windows exists, or define an alternate access method for Windows using protocols from that world, such as VNC or Windows Remote Desktop.

-- SimonLeinen - 17 Aug 2005