(Reply-To set to openssh-unix-dev only)
Dean Anderson wrote:
On Mon, 26 Jan 2004, Jeffrey Hutzelman wrote:
Sadly, this doesn't make any difference. OpenSSH 3.7.1 and later run PAM
session modules in a subprocess unrelated to the eventual user shell,
That is not correct. Even with privsep,
Putty 5.3 didn't work with the afs-supplied afs pam module. and 3.7.1p2...
but maybe this can be fixed. Certainly, its a step.
My point though, is that the openssh should use the system (pam) routines
if it doesn't have any other method negotiated. Presently, it will only
try to directly check
On Monday, I proposed a alternative method of obtaining and AFS PAG and
token when used with OpenSSH or any other deamon.
I now have a test working using openssh-snap-20040122.
This relies on an external program referred to as get-afs-token
which accepts at least two parameters:
-setpag
I'd like to second Doug's idea as a potential solution for OpenSSH at
least.
Kerberos mailing list [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos
Really? Is there any links to what was avoided? I'd like to look at
these in detail before I concede that anything of values has been
demonstrated. I've heard these claims before, but I could not find any
substantiating details---the claims are dubious at best.
--Dean
On Tue,
Rather then implementing kafs in MIT Kerberos, I would like to
suggest an alternative which has advantages to all parties.
The OpenSSH sshd needs to do two things:
(1) sets a PAG in the kernel,
(2) obtains an AFS token storing it in the kernel.
It can use the Kerberos credentials
Jeffrey Altman wrote:
Douglas E. Engert wrote:
In its simplest form, all that is needed is:
system(/usr/ssh/libexec/aklog -setpag)
You would probably want this to be a configurable option in the sshd
configuration file
as opposed to have a fixed name, location and options which
I don't disagree with your proposal at all. Sounds good. It should
make it easier to fix/change things in the future.
But. . .
Isn't the reason this keeps coming up that AFS client doesn't
(can't?) behave like a normal Kerberos application and just get it's
own service ticket when it needs
Henry B. Hotz wrote:
I don't disagree with your proposal at all. Sounds good. It should
make it easier to fix/change things in the future.
But. . .
Isn't the reason this keeps coming up that AFS client doesn't
(can't?) behave like a normal Kerberos application and just get it's
own
On Monday, January 26, 2004 11:23:34 -0800 Henry B. Hotz
[EMAIL PROTECTED] wrote:
Isn't the reason this keeps coming up that AFS client doesn't (can't?)
behave like a normal Kerberos application and just get it's own service
ticket when it needs one (based on an existing tgt)? The real reason
We have implemented the strategy similar to the one that Douglas suggested
in his posting. In our case (Heimdal) we allow user to login using his/her
K5 password and then call Heimdal afslog inside session.c:
system(/usr/sshutils/sbin/afslog /dev/null 21);
A small complementary trick
On Monday, January 26, 2004 17:17:46 -0500 Dean Anderson [EMAIL PROTECTED]
wrote:
On Mon, 26 Jan 2004, Jeffrey Hutzelman wrote:
Worse, it would not solve the problem. The trouble here is not that AFS
tokens are stored in a kernel data structure instead of a file. It's
that they are indexed
Dean Anderson wrote:
Right. And there is an easy solution: Turn off Privsep. A process that
creates new user sessions needs root privileges, and those privileges
cannot be given away prematurely to improve security. Privsep is just a
stupid idea for some programs. Probably for most
Jeffrey Hutzelman wrote:
On Monday, January 26, 2004 17:17:46 -0500 Dean Anderson [EMAIL PROTECTED]
wrote:
On Mon, 26 Jan 2004, Jeffrey Hutzelman wrote:
Worse, it would not solve the problem. The trouble here is not that AFS
tokens are stored in a kernel data structure instead of a file. It's
On Mon, 26 Jan 2004, Jeffrey Hutzelman wrote:
Worse, it would not solve the problem. The trouble here is not that AFS
tokens are stored in a kernel data structure instead of a file. It's that
they are indexed by a value which must be set on login, inherited from each
process by its
15 matches
Mail list logo
