Real one-time passwords (OTP) on Linux other than S/Key?

Question

Surely it is no good idea to log into a remote system from an untrusted computer. But sometimes it is plain necessary. Exposing an unencrypted SSH keyfile is no option of course. Entering a regular password is none either.

S/Key seems to be the "usual" solution but it requires strictly following the order of passwords on a list. This is undesirable for shared accounts as all parties would need to synchronize use of the list.

Any way to make OTPs with no requirements regarding order of usage? Other ideas?

Background: Two admins share an account. Another one should be given an "emergency envelope" that is sealed and contains information for that account. Breaking the seal is allowed only in case the other admins are unavailable.

Solution 1

We use OTPW for this. Simple implementation. Easy to replicate the password list. The system requests passwords by number, so no problems trying to keep the lists in sync.

Solution 2

S/Key is ideal for this scenario, but you need to do a little more work.

Create special accounts for each emergency envelope. Those accounts are added to sudoers and can assume root. That gives you the audit trail that you should have (one account per envelope, one envelope per user) and the flexibility that you need.

After an emergency, the admin has to bring back the envelope for the next password, which gives you the audit trail.

Solution 3

take a look at mobile-otp - it's 'cheap' soft-token you can run on java-capable mobile phone. i used it successfully only with web-apps, but as i see they have pam module as well.

alternatively there is wikid, but i never used this one.

Solution 4

I've been a fan of Yubikey for a while now.

http://www.linuxjournal.com/article/10166

Solution 5

The issue seems to be that you're trying to use group accounts. I see two possibilities

1. Separate logins for each user, and then have them su to the shared account.
2. If the OS supports it, assign two logins the same UID number.

In the second case, you'll have to test what s/key thinks a user is (UID, or UID number) and if you can assign each login a separate list.

(I admit -- I've never tried #2 in Linux, but we used to use it a long time ago to give the operators an alternate shell, which was actually a menu system for them to run some fixed commands as root. These days, you'd just do it w/ sudo)

View more solutions

Comments

[Admin]

This is a design question. You need one account with several authentication "items". Just like you could add several ssh pubkeys to this account and put the superlong root-password in the safe. In regards to using a second factor other than ssh keys, you need a system, that can handle this. You can use privacyIDEA as a central system, to manage the authentication devices/items of all the admins, which are assigned to this root-account. Then you can configure all your hardy-systems to authenticate against this central privacyidea.

[Thomas]

Me too. I log in to BSD, Linux and Solaris boxes with Yubikey. Cheap and awesome.

[Paul]

This is exactly what I was looking for. There are even packages for Ubuntu Hardy. I would upvote, but can't (yet).

[Paul]

Not exactly what I want, but thanks for noting the missing audit trail if accounts are shared.

[duffbeer703]

The assigning two logins the same UID option that Joe H. suggested is probably the best course of action then.

[Return_Of_The_Archons]

Our production systems are Hardy, so I can say with confidence that it works well on that platform. And even though you may not be able to upvote, you can "accept" the answer... :)