It would be nice to have the option of using a different password for lish from the member login password to the web page. Access to the console and access to the web configuration are distinct activities, and it might make sense to protect them separately.

I'm thinking in particular about times when one might need to log in to the console from an unsecure computer, say to fix sshd or to look at console output. A keystroke logger could pick up the lish password.

Unauthorized entry to lish wouldn't be immediately devastating, but unauthorized configuration access would be. An intruder could simply create another boot disk and mount everything. If the passwords were different, the bad guy would have to find another vulnerability in lish.

I know we can use public key authentication for lish and I actually carry my ssh private keys around with me on a small flash drive, but it isn't always feasible to plug it in (no USB ports, no flash drive driver, etc.) and I'd rather not attach it to a random machine if I don't have to.

If I could get into lish at an acceptable risk level, then I could log into my Linode with opie (one-time password). I'll need to change the lish password as soon as I can get to a secure machine, but a keystroke logger would only get behind that one layer of security.

Although this is pretty easy for me to implement, there are a few issues.

Eventually most of the functionality of the LPM will be available via Lish. So someone with access to Lish could make configuration changes, delete/create filesystems, reverse dns, rebooting (single user mode), etc. About the only thing Lish isn't going to have is handling billing information.

If you're on a machine that might have a keystroke logger, what good is logging into Lish now anyway? Once logged into Lish, you'd still have to type in your root password at some point to do anything useful (like repairing a service).

I've had requests for a separate password for the "My Profile" member's section -- that way members can provide a password to get into the LPM to their developers, but keep them out of the billing stuff...

-Chris

You can use a one-time password like opie (or s/key). There is a pam module for opie, so it's easily configured to work in combination with the main password.

There are other alternatives, such as SecureID or SafeWord, which essentially store a password list in a unique piece of hardware (instead of on a piece of paper). These are rather expensive. Another scheme I've just heard about allows you to use your cell phone or wireless PDA to acquire a one-time password over an SSL link.

That's intersting! That's a really great idea. I wonder if I could setup opie access to Lish itself. /me investigates

The only catch with using it with OpenSSH is the issue of having only one of pam support or privilege separation. pam is needed for opie; privilege separation is needed so that any OpenSSH vulnerability might not result in root access.

I have heard that the very latest versions (3.8?) of OpenSSH have both working together, but I haven't tried it. I personally prefer staying with the official Debian stable stuff for that sort of thing.

hrm. How well would S/Key work? I'm still reading up on things...

The way I understand things is that S/Key support is a build configuration option in OpenSSH. I don't know if everything is already included in the source tarball or if it requires external headers/libraries. I also don't know if it includes the utilities to generate the keys.

It sounds to me that if OpenSSH is built with the S/Key support option, then pam is not needed and PrivilegeSeparation can be on. There have been old security issues with OpenSSH and S/Key, but it looks like they have all been closed.

On the other hand, if you have to build OpenSSH anyway then perhaps the bleeding edge of pam/opie is the way to go. I haven't seen an authoritative declaration that this is fixed, though. I'm basing that assumption on this:

http://tinyurl.com/2lx8b
http://tinyurl.com/2dnhj