Why did we change public key authentication?

Why did we change public key authentication?

Public key authentication allows users of ssh to prove their identity (authenticate) without the use of a password. The authentication is based on the private key which corresponds to the public key which is known to the remote machine. This public key is placed by the user in a known file on the remote machine. We have modified this scheme such that the user does not have direct access to the place where the public key is stored. The key pair must be obtained through a web interface. Further, we have restricted the lifetime of the key pair issued to 8 hours. A number of people find this unreasonable and have asked why.

As you may be aware, we have tightened up password-less access methods in the past. We modified authentication code so that .rhosts was not honored for other users or from hosts which we did not trust. And we never put hosts in hosts.equiv which we did not administer. The reasoning behind this was that a compromise on an untrusted machine could be parlayed through these mechanisms into an account on our machines.

While public key authentication uses strong encryption algorithms to verify who you are and encrypts traffic over the connection, the private key, which is all you need to prove identity, is only protected by a pass phrase chosen by the user. The documentation suggests you choose a long, relatively meaningless pass phrase for this, it enforces nothing. Not even a length requirement. Human nature being what it is (and I've seen some of the passwords users have chosen in the past when did not enforce some kind of complexity on passwords chosen), some people will choose short, guessable pass phrases. Some will even choose an "empty" pass phrase, so they can just hit return when prompted for it. (We have in the past come across "root" accounts on user administered machines with no password!) It's likely that those who take such care in protecting their private keys will also be neglectful in keeping their machines current with security patches and updates. We cannot leave our machines continuously subject to the security decisions of all our users!

But completely disabling public key authentication places our users at a great inconvenience. Each time a new connection was established, the user would have to retype their password. In some cases, such as checking in a set of files to a CVS repository, this could be many times! We discussed the issue at an LCSR Users Group meeting and reached a compromise. We would allow public key authentication for a relatively short time, but long enough so as not to be a burden on the user. The period of 8 hours was agreed upon. In order to prevent the user from repetitively using the same key pair, key pairs would be issued by us. The public key would be stored in a place under our control; the private key returned to the user to be protected as they see fit. To limit the lifetime, we would periodically scan the public keys, removing any older than the specified period.

So why do we care if a user's password or public key is compromised?

Some people ask why they should care if someone else's account is compromised or why someone should care if their own account is compromised. Surely, they are only an unprivileged account, so it's only their own files which are in jeopardy. If someone is lax in protecting their files and lose something by it, they get what they deserve, some might say.

But even unprivileged access grants an unwanted visitor much more access to files accidentally or deliberately left unprotected to the user community of the system involved. And the compromised user may also be a member of a group for file maintenance. An intruder would then be able to modify or delete any shared files.

Also, many root compromises require local user access to attempt. No system, even one fully patched, is secure from all attacks which exist. We'd rather keep unwelcome visitors out than rely on security once they're in.

This page last updated March 1, 2004.