Multiple authentication methods at the same time?

[Thomas A. Fine]

One of the things I love on the Internet (and by love I mean hate) is 
when someone asks a technical question, and they end up with a 
condescending policy answer.

The first thing anyone should know (but many don't) about security is 
that everybody has different security needs, and their policy is their 
own business.  People who go around saying A is secure and B is 
insecure, and never use B and always use A, these people really do not 
understand the first thing about security.

Having said that, I'll answer your "questions".  We used to use a mix of 
public key and password for ssh at the user's discretion.  We found 
ourselves in a situation where we had a few breakins, all of which 
appeared to be compromised private keys that had been stolen from remote 
accounts.  So we decided to try going without public key authentication 
for a while and see how that worked out.  One can argue about the wisdom 
of this decision, and I think it's an interesting debate without a clear 
and obvious winner.

At any rate, we have seen some new break-ins lately, and they have been 
compromised passwords (and one sshd out-of-date with a known bug). 
Whether our policy really helped, i.e. there would have been additional 
private key break-ins, is unknowable.  At any rate it doesn't matter, we 
are moving forward.

In many (though not all) of these breakins, we have seen attackers 
collecting private keys from every account they have compromised.  In 
one case where root was obtained, a fake ssh was installed which in 
addition to collecting passwords, also collected private keys and 
passphrases.

For us, our first improvement will be improved auditing, and data 
collection (hence the DMZ).  We'll be profiling our users and 
hand-checking logins that don't match their profile.  The DMZ also makes 
it harder on the hackers.  Initially of course, two passwords instead of 
one is only a slight improvement (if any).  But one option is in fact to 
  allow pubkey at one of the two steps (and not the other).  This gives 
a kind of soft, sort-of two-factor authentication, as the hacker has to 
both sniff a password and steal a private key (from different locations).

Another option is OTP.  This gives us real two-factor authentication 
(depending on which flavor/implementation we pick).  And a parent 
organization is likely going to mandate this eventually anyway so we 
might as well get started.

Of course, we do not want to expose any authorization or authentication 
data out to the DMZ if we don't have to, so once a hacker gets on the 
DMZ they don't have much to play with.  This is why building everything 
into radius makes sense.  The hackers have nothing to crack and nothing 
to steal, only a port to poke, and not very many times without us 
noticing.  If OTP seeds had to be stored out in the DMZ, this would not 
meet our security needs.

So, thank you for attempting to dictate my security policy to me in the 
absence of any information about me.  And even though we feel that 
pubkey is woefully inadequate security on it's own, I won't tell you not 
to use it, because I know nothing about your security needs, and can't 
begin to attempt to offer policy advice to you without significant 
additional information.

    tom

On 2/16/11 6:02 PM, Alexander Clouter wrote:
> Thomas A. Fine<fine at head.cfa.harvard.edu>  wrote:
>>
>> I thought this would be easy but now I'm wondering if it will be
>> possible at all.  We are transitioning to a DMZ for all ssh logins.
>> During phase one, people will use a standard (but different than
>> internal) password which will be obtained either through LDAP or
>> the passwd module (we just haven't picked one yet, either should
>> be fine).
>>
> Why?  Just use public-key auth.
>
> Slap all your keys in LDAP, my fuse program caches keys incase your LDAP
> servers go walkies:
>
> http://www.digriz.org.uk/lpkfuse
>
> It's 2011, stop using password auth for SSH. :)
>
>> But eventually the DMZ ssh will need to be OTP.  So I wanted to
>> be able to offer OTP as an option during transition for people to
>> try out and get used to while still being able to use their other
>> traditional password.
>>
> This sort of thing I probably would solve with PAM.  Put in your
> /etc/pam.d/sshd file something like:
> ----
> auth    sufficient   pam_radius_auth.so
> auth    required     pam_opie.so
> ----
>
> SSH will try public-key, then fall onto password auth with RADIUS, then
> fall onto OTP's (via OPIE).  You could replace pam_opie.so with another
> pam_radius_auth.so instance but pass 'conf=/etc/alt-config'.
>
>> So fallback in the case of one method (e.g. LDAP) being unavailable
>> is pretty easy.  But in this case both methods would be available,
>> and I'd want to test the password against both methods.
>>
> For OTP to work, the user needs to be presented with a challenge, so get
> them to send a blank password (use unlang in authorize to catch this),
> then a challenge is returned and the auth becomes OTP (even if the
> challege is "Reply-Message := What does your fob say?".
>
>> Is this even possible?  It seems like once it has found a working
>> module in authorize, it can only use that one module in authenticate.
>>
>> What's the solution?
>>
> Use PAM, it could be done with RADIUS, but for SSH you really need to
> join the rest of us here in 2011 :P
>
> Cheers
>