On 2/16/11 5:36 PM, Gary Gatten wrote:

I don't understand the question 100%. If you want different users to test different methods (LDAP, OTP, etc.) - that's fairly easy. If you want a given user "Bob" to test different methods concurrently, that sounds tricky - and I'm not sure what you wish to accomplish with that... You MAY be able to do something with "Fallthrough" and "Post Auth" - but again, I'm not exactly sure what you're trying to accomplish...

Yeah, I want Bob to be able to do both. So if Bob is game to be a test subject during transition, I don't want to penalize him by locking him out if he or we screw up the OTP configuration. If I wanted an either/or for each user, that just happens right? if otp is listed first, it will only be selected if the user exists, otherwise it will move on to LDAP (or whatever). So I either add Bob to the OTP database and he uses OTP, or I leave him out and he uses LDAP. This is not what I want, I'm just trying to make sure I understand what it's trying to do. tom

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@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

Thomas A. Fine <fine@head.cfa.harvard.edu> wrote:

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.

Welcome to the Internet, the place where tongue-in-cheek evaporates...

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.

When you look for advice on how to do xyz, please do not take it as an insult when someone: a) answers your question on how to do xyz (and gives two solutions) b) suggests doing abc would possibly be more appropriate A lot of people do not know about public-key auth even today, many do not know you can put the lot in LDAP too. Putting this knowledge on the list is not just for your benefit, it's also for archive readers....and to pimp-up my Google listing :)

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.

Ours seemed to be due to keyloggers and/or password sharing; I work as a network sysadmin for a small university in the UK.

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.

If OTP seeds had to be stored out in the DMZ, this would not meet our security needs.

That's actually incorrect, there have been OTP systems that do not rely on seeds, and a root compromise of a system does not harm the I would normally recommend a type of OTP, but I am getting the impression that the only recommendations you are interested in hearing are unfortunately your own which is a shame; you seem to know things that I also want to know.

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.

That is completely incorrect, for me. I *want* to hear what you are doing and also your raw ("if you lived in utopia, I would do xyz") recommendations so that I can evaulate them all and make a more informed choice. It might seed my brain with something that sparks a far better solution. Cheers -- Alexander Clouter .sigmonster says: "I'd love to go out with you, but I have to floss my cat."

Christ Schlacta <lists@aarcane.org> wrote:

Individual SSH keys are so 2010, you legacy SSHers need to get an SSH CA setup so you can just sign all your keys and deploy a single master certificate like the rest of us.

You can do that? /me goes to investigate Cheers -- Alexander Clouter .sigmonster says: BOFH excuse #47: Complete Transient Lockout