Thomas A. Fine <fine@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 -- Alexander Clouter .sigmonster says: You will be winged by an anti-aircraft battery.