4

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.

Paul
  • 1,890
  • 3
  • 18
  • 24
  • 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. – cornelinux Jul 21 '15 at 13:19

10 Answers10

10

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.

Insyte
  • 9,314
  • 2
  • 27
  • 45
  • This is exactly what I was looking for. There are even packages for Ubuntu Hardy. I would upvote, but can't (yet). – Paul Aug 31 '09 at 15:02
  • 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... :) – Insyte Sep 01 '09 at 00:31
4

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.

duffbeer703
  • 20,077
  • 4
  • 30
  • 39
  • Not exactly what I want, but thanks for noting the missing audit trail if accounts are shared. – Paul Aug 31 '09 at 15:16
  • The assigning two logins the same UID option that Joe H. suggested is probably the best course of action then. – duffbeer703 Aug 31 '09 at 16:16
3

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

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

Tatas
  • 2,091
  • 1
  • 13
  • 19
  • Me too. I log in to BSD, Linux and Solaris boxes with Yubikey. Cheap and awesome. – Thomas Aug 30 '09 at 10:05
  • YubiPAM provides an offline-PAM module as you would expect it. The hardware seems slick. Not clear if the necessary storage of the AES key on the target computer implies a risk to the integrity of the Yubikey (i.e. login without Yubikey can be achieved by having the AES key). – Paul Aug 31 '09 at 15:38
3

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)

Joe H.
  • 1,897
  • 12
  • 12
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.

pQd
  • 29,561
  • 5
  • 64
  • 106
2

This is an old thread but someone might stumble upon it. There are two interesting requirements:

  1. one account shared by several human beings

  2. the emergency envolope, which I think should only work one time.

LinOTP can cope with that. You can assign several different OTP tokens of different vendors to one user. (req. 1)

Additionally you may create a fixed password token. Put this in the envelope. Now comes the cool part: you can define how often a token may be used for successful authentication. So you can set this value=1 for this emergency envelope token (req. 2)

Cornelius
  • 21
  • 1
1

Things like Vasco Vacman provide RADIUS authentication, which you could use to log into linux using regular PAM. They require a physical token, and are pricey though, so probably don't suit your current situation.

Cian
  • 5,777
  • 1
  • 27
  • 40
1

Another strong authentication alternate would be RSA SecurID.

Pros: Many factors to choose from, from the "classic" keyfob device, to software tokens (including iPhone!) to "OnDemand" (i.e., OTP codes sent via SMS/email) that is what I would probably use for this case. (ie, you have all the "options" mentioned in the article)

Pros: Easy to integrate with almost any system, enabling strong auth into most systems

Pros: Easy to use, from the end-user POW.

Cons: Price. It's not the cheapest solution in the market.

JJarava
  • 167
  • 2
  • 9
1

I used to use OPIE. It asks for the passwords by number, so you know which one on the list it wants.

But now I've moved on to Yubikey.

Thomas
  • 1,446
  • 11
  • 16
1

I don't understand why the standard S/Key won't meet your requirements.

Every time someone logs in, it sends them a visible "challenge" which includes the index number of the password it wants. Enough information is given to figure out which line of a printed list of one-time-passwords is being requested ...without any sort of coordination with any other user sharing the account. (Another way to look at this is all necessary coordination is provided by the computer itself, with no need for the multiple users to ever talk to each other.) Similarly there's enough information (both the index number and the seed) to give to a program to regenerate the requested password (provided of course you know the secret).

The envelope can contain either another printed copy of the whole list of one-time passwords, or the original (non-skey) password, which still works. (Of course for maximum security, if the envelope is ever opened you want to change whatever it contained [either the sequence of OTPs or the original password].)

So skey seems to easily fulfill both requirements. Tell me again why you're searching for something different?

Chuck Kollars
  • 111
  • 1