Re^2: How can I write a Kerberos service in Perl?

The users don't have permission to log in interactively on the servers in question, and it's rather important to the security model that this should remain the case.

I don't think PAM is any help to me here since as I understand it, there is no mechanism to pass PAM the user's existing credentials, for it to pass on in turn to the kerberos libraries.

From reading around I think the answer involves GSSAPI, which there is a CPAN module for but which will take me some time to digest!

Comment on Re^2: How can I write a Kerberos service in Perl?

Replies are listed 'Best First'.
Re^3: How can I write a Kerberos service in Perl? by Fletch (Bishop) on Jan 14, 2008 at 16:31 UTC
OpenSSH can be configured to only allow users to run certain commands rather than being given a login shell. You should be able to setup an otherwise unprivileged account which can only run "sudo start_my_service" (and I believe the authenticating SSH key is available to that so you could link back to the remote user). I'd just be more comfortable using something off the shelf and highly visible (that's been gone over by lots of eyeballs) like OpenSSH before going it alone. (Not that you're doing it completely from scratch since you'd be using a sane and tested interface in GSSAPI, just that any bugs you put in (and we all are bound to put them in sometime . . . :) in your implementation wouldn't be subject to external scrutiny)) (And I was afraid PAM would be a wild goose chase; now that I think about it it's more about controlling local authorization once the remote side's authenticated. NEED MOR CAFFEINE . . . ) The cake is a lie. The cake is a lie. The cake is a lie.	[reply]

Replies are listed 'Best First'.

Re^3: How can I write a Kerberos service in Perl?
by Fletch (Bishop) on Jan 14, 2008 at 16:31 UTC

OpenSSH can be configured to only allow users to run certain commands rather than being given a login shell. You should be able to setup an otherwise unprivileged account which can only run "sudo start_my_service" (and I believe the authenticating SSH key is available to that so you could link back to the remote user).

I'd just be more comfortable using something off the shelf and highly visible (that's been gone over by lots of eyeballs) like OpenSSH before going it alone. (Not that you're doing it completely from scratch since you'd be using a sane and tested interface in GSSAPI, just that any bugs you put in (and we all are bound to put them in sometime . . . :) in your implementation wouldn't be subject to external scrutiny))

(And I was afraid PAM would be a wild goose chase; now that I think about it it's more about controlling local authorization once the remote side's authenticated. NEED MOR CAFFEINE . . . )

The cake is a lie.
The cake is a lie.
The cake is a lie.

[reply]