Hello all,

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?

I've never tried this, but I'd guess that you'd need to modify /etc/pam.d/system-auth so that the "auth" entry for pam_unix is changed from sufficient to required and then a line straight after that for auth sufficient pam_your_rsa_function.so

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.

_________________
Rgds
Stephen
(Linux user since kernel version 0.11)

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.

_________________
Disclaimer: I am no longer employed by Linode; opinions are my own alone.

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

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

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.

_________________
Disclaimer: I am no longer employed by Linode; opinions are my own alone.