Question regarding two factor authentication (Rsa secureid)
I'm asking this here as whilst this will not be deployed on a linode yet (will be in the future), the technical expertise of members here far surpasses any mailing list I've seen on the net.
I'm trying to implement RSA secureid two factor authentication with some RHEL5 servers. Essentially, the end user needs to be able to enter a password he chooses (preferably set by standard passwd command), and then his secureID token's generated code.
For the life of me I cannot find a way to make what I would IDEALLY like to happen occur. (When first ssh'd to machine, or logging in, it prompts you for your regular password, then passcode.) I cannot seem to find a way to make SSH especially prompt for two diff authentication modules in PAM. (I've gotten it prompting for my code without issue, but not both one after eachother.)
I've managed to look into using the "pin" feature of RSA, but this basically means all password changes need to be done from the RSA devices and not on the system at all.
Has anyone had any experience with these devices in accomplishing what I'm attempting to? Or even remotely close? Or am I talking to /dev/null?
4 Replies
eg
auth required pam_env.so
auth required pam_unix.so nullok try_first_pass
auth sufficient pam_your_rsa_function.so
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
and then make sure "usepam yes" is set in sshd_config.
Again, that's just a guess
You might find it easier to play with telnet first, rather than ssh, since ssh usage of PAM is sometimes idiosyncratic. So get PAM working first, then get ssh working with PAM.
Been to locked-out land, got a T-shirt.
@jed:
A suggestion for messing with PAM remotely: leave a SSH session open and never close it. You can restart sshd and not drop your current session. Turn off ControlMaster if you're using it and force your client to open a new connection to your Linode to test your changes. Think very carefully about everything you're doing.
Been to locked-out land, got a T-shirt.
… And have a root window open on the console, and have tested emergency fix processes via Finix so you can recover:-)
Actually, "ControlMaster" is an important point; secondary logins via a shared connection do not authenticate and reuse the access granted by the master session. I'm of two minds as to whether that's a good idea, but it's how ssh works.
@sweh:
I'm of two minds as to whether that's a good idea, but it's how ssh works.
It pisses me off when I ^D a shell and then it hangs because it's my master, so I might be with you. I'm inclined to think the convenience wins out, though.
Nothing like closing a tab hard and kicking three other connections off, though…
Here and there, here and there. Threadjack abort, original discussion commence.