Original Question
Fletcher Cocquyt fcocquyt at stanford.edu writes:
Hi,
I am attempting to get our Solaris 9 and 10 servers to use campus kdc for ssh
authentication.
I want to end up with a cookbook of step by step instructions on how to
convert a fresh install of Solaris to
On Mar 31, 8:22pm, Jeffrey Hutzelman wrote:
} Subject: Re: Solaris ssh pam_krb
But in a multi-application PAG world, _no_ application can directly
use the real PAG ID as an identifier, because it changes too much.
Instead they need an application-specific identifier. That applies
On Tue, Apr 04, 2006 at 12:29:04PM -0500, [EMAIL PROTECTED] wrote:
On Mar 31, 8:22pm, Jeffrey Hutzelman wrote:
} Subject: Re: Solaris ssh pam_krb
But in a multi-application PAG world, _no_ application can directly
use the real PAG ID as an identifier, because it changes too much
Let's uplevel a bit.
To me PAGs provide a useful distinction between processes in some sort
of session, sharing some common characteristics, one that is better than
environment variables in that it is easily (cheaply) observable from the
IPC peers.
PAGs have, for me, at least these uses:
- As
On Monday, April 03, 2006 11:11:14 AM -0500 Nicolas Williams
[EMAIL PROTECTED] wrote:
Let's uplevel a bit.
To me PAGs provide a useful distinction between processes in some sort
of session, sharing some common characteristics, one that is better than
environment variables in that it is
On Mon, Apr 03, 2006 at 01:23:48PM -0400, Jeffrey Hutzelman wrote:
On Monday, April 03, 2006 11:11:14 AM -0500 Nicolas Williams
[EMAIL PROTECTED] wrote:
Let's uplevel a bit.
To me PAGs provide a useful distinction between processes in some sort
of session, sharing some common
On Mon, Apr 03, 2006 at 02:27:36PM -0400, Jeffrey Hutzelman wrote:
Now, the issue is that when you're talking about a caching distributed
filesystem, your identity affects not only what credentials are used to
establish connections to fileservers on your behalf, but also what you
are allowed
On Mon, Apr 03, 2006 at 02:27:36PM -0400, Jeffrey Hutzelman wrote:
On Monday, April 03, 2006 12:56:34 PM -0500 Nicolas Williams
[EMAIL PROTECTED] wrote:
That I'd rather count references to network credentials from sessions
than from processes that might have done a seteuid() to temporarily
On Sat, Apr 01, 2006 at 12:13:31AM -0500, Ken Hornstein wrote:
Ken is wrong.
Careful, now :-) When I was agreeing with Nico, I was specifically
talking about storing Kerberos tickets in the kernel versus something
in userspace. I think that there is no technical reason you cannot
have a
On Monday, April 03, 2006 02:01:21 PM -0500 Nicolas Williams
[EMAIL PROTECTED] wrote:
On Mon, Apr 03, 2006 at 02:27:36PM -0400, Jeffrey Hutzelman wrote:
Now, the issue is that when you're talking about a caching distributed
filesystem, your identity affects not only what credentials are
On Mon, Apr 03, 2006 at 04:43:07PM -0400, Jeffrey Hutzelman wrote:
On Monday, April 03, 2006 02:01:21 PM -0500 Nicolas Williams
[EMAIL PROTECTED] wrote:
On Mon, Apr 03, 2006 at 02:27:36PM -0400, Jeffrey Hutzelman wrote:
Since you've agreed that PAGs are not a session separation feature I'll
On Monday, April 03, 2006 02:08:46 PM -0500 Nicolas Williams
[EMAIL PROTECTED] wrote:
File descriptors in Solaris already retain a reference to the cred_t
used to open the file. So UID or PAG is not relevant here. Neither
is processes with that UID or PAG. What is relevant is references
I have lots of uses for PAGs besides tracking krb5 tix. I don't want a
PAG-like item per-such use. I want a daemon (least priv and all that)
that tracks PAG-{whatever} associations.
I'm curious ... why do you want a userspace daemon to be involved? I think
you could simplify things by making a
On Fri, Mar 31, 2006 at 01:27:49PM -0500, Ken Hornstein wrote:
I have lots of uses for PAGs besides tracking krb5 tix. I don't want a
PAG-like item per-such use. I want a daemon (least priv and all that)
that tracks PAG-{whatever} associations.
I'm curious ... why do you want a userspace
First-class multi-application PAGs would not be so cheap in the kernel,
and there would have to be a finite number and registry of applications
to prevent resource consumption attacks. Adding applications to the
registry would be a complication (you don't want to have to reboot for
that)
Why store tickets in the kernel, what's the point? Presumably you'd not
want anything other than TGTs in the kernel, so where do you cache
service tickets? Or do you want all tickets in the kernel? (Presumably
in pageable, accounted memory...).
Well, actually, I'd rather have the whole ticket
While you are thinking about PAGs, how do you handle Solaris zones
with PAGs?
AIX and HPUX had a PAG field in the creds to be used with DFS.
Since DFS come out of Transarc then part of IBM and since DFS was
based on AFS, they may have gotten their kernel people to add the
field so the PAG could
Ken Hornstein wrote:
Why store tickets in the kernel, what's the point? Presumably you'd not
want anything other than TGTs in the kernel, so where do you cache
service tickets? Or do you want all tickets in the kernel? (Presumably
in pageable, accounted memory...).
Well, actually, I'd
On Fri, Mar 31, 2006 at 03:41:13PM -0600, Douglas E. Engert wrote:
While you are thinking about PAGs, how do you handle Solaris zones
with PAGs?
The simple kernel PAG approach is orthogonal to zones: your pag_t's will
be unique to the whole system, zones or not. The filesystem namespace,
and,
On Friday, March 31, 2006 03:44:57 PM -0600 Douglas E. Engert
[EMAIL PROTECTED] wrote:
Ken Hornstein wrote:
Why store tickets in the kernel, what's the point? Presumably you'd not
want anything other than TGTs in the kernel, so where do you cache
service tickets? Or do you want all
On Fri, Mar 31, 2006 at 04:39:57PM -0500, Ken Hornstein wrote:
Why store tickets in the kernel, what's the point? Presumably you'd not
want anything other than TGTs in the kernel, so where do you cache
service tickets? Or do you want all tickets in the kernel? (Presumably
in pageable,
Which attacks are we talking about? Attacks on the /tmp/krb5cc_uid
scheme? Yes, that's weak. But it is absolutely not the case that all
user-land schemes are inherently subject to that sort of attack; in
fact, modern architectures and operating systems provide lots of
facilities, beginning with
On Fri, Mar 31, 2006 at 04:56:27PM -0500, Jeffrey Hutzelman wrote:
On Friday, March 31, 2006 03:44:57 PM -0600 Douglas E. Engert
[EMAIL PROTECTED] wrote:
The caches I see are tiny,
Unless the the KDC is Windows, and the tickets have PACs. A tgt is 2000
bytes,
If you're using Kerberos V for authentication in remote administration
protocols and have, say, 30,000 hosts to look after then your ccache
would grow to:
14KB x 30,000 = *huge* (~410MB)
Oh, come on ... this is a strawman argument. You'd have to make some
serious changes to make this work with
On Fri, Mar 31, 2006 at 05:17:10PM -0500, Ken Hornstein wrote:
Which attacks are we talking about? Attacks on the /tmp/krb5cc_uid
scheme? Yes, that's weak. But it is absolutely not the case that all
user-land schemes are inherently subject to that sort of attack; in
fact, modern
On Friday, March 31, 2006 04:20:48 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
On Fri, Mar 31, 2006 at 04:56:27PM -0500, Jeffrey Hutzelman wrote:
On Friday, March 31, 2006 03:44:57 PM -0600 Douglas E. Engert
[EMAIL PROTECTED] wrote:
The caches I see are
On Fri, Mar 31, 2006 at 05:38:30PM -0500, Ken Hornstein wrote:
If you're using Kerberos V for authentication in remote administration
protocols and have, say, 30,000 hosts to look after then your ccache
would grow to:
14KB x 30,000 = *huge* (~410MB)
Oh, come on ... this is a strawman
On Fri, Mar 31, 2006 at 06:17:53PM -0500, Jeffrey Hutzelman wrote:
On Friday, March 31, 2006 04:20:48 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
What other kernel-land applications can you think of or imagine that
fundamentally needs direct multi-application PAG support in the kernel
I agree that you can design a user-land scheme that's a lot better than
a simple file, but there are enough tools available for grovelling through
a user-level daemon's memory that I would prefer to have something better.
Again, it's not 100%, but it's all a matter of degree.
One tool name:
On Fri, Mar 31, 2006 at 06:29:57PM -0500, Ken Hornstein wrote:
I agree that you can design a user-land scheme that's a lot better than
a simple file, but there are enough tools available for grovelling through
a user-level daemon's memory that I would prefer to have something better.
On Friday, March 31, 2006 05:24:04 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
On Fri, Mar 31, 2006 at 06:17:53PM -0500, Jeffrey Hutzelman wrote:
On Friday, March 31, 2006 04:20:48 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
What other kernel-land applications can you think
On Fri, Mar 31, 2006 at 07:07:43PM -0500, Jeffrey Hutzelman wrote:
On Friday, March 31, 2006 05:24:04 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
- Encrypted (local) filesystems
Orthogonal to PAGs. The kernel needs to know keys for encrypting
objects/filesystems, but access
On Friday, March 31, 2006 06:27:22 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
On Fri, Mar 31, 2006 at 07:07:43PM -0500, Jeffrey Hutzelman wrote:
On Friday, March 31, 2006 05:24:04 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
- Encrypted (local) filesystems
Orthogonal to
Really, I think the introduction of a new process to keep track of
PAG-appid mappings is just silly. The number of PAG application types in
the system is likely to be quite small, and the mappings themselves are
small as well. Why not just store them in the PAG structure and be done
with it?
The encrypted filesystem argument holds no water, IMO. Ken H. agrees
that all other kernel-side applications can upcall to do PAG-stuff
resolution if need be. What's left?
Ken is wrong.
Careful, now :-) When I was agreeing with Nico, I was specifically
talking about storing Kerberos
On Wednesday, March 29, 2006 04:12:12 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
On Wed, Mar 29, 2006 at 03:53:33PM -0600, Douglas E. Engert wrote:
Nicolas Williams wrote:
On Wed, Mar 29, 2006 at 03:24:24PM -0600, Will Fiveash wrote:
On Wed, Mar 29, 2006 at 10:02:54AM -0600,
On Thu, Mar 30, 2006 at 06:58:39PM -0500, Jeffrey Hutzelman wrote:
On Wednesday, March 29, 2006 04:12:12 PM -0600 Nicolas Williams wrote:
The last two supplementary groups add up to a PAG thing? That won't
go over well :)
Actually, that's what AFS does, except it's the _first_ two groups;
On Thursday, March 30, 2006 06:08:10 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
On Thu, Mar 30, 2006 at 06:58:39PM -0500, Jeffrey Hutzelman wrote:
On Wednesday, March 29, 2006 04:12:12 PM -0600 Nicolas Williams wrote:
The last two supplementary groups add up to a PAG thing? That
On Thu, Mar 30, 2006 at 08:02:14PM -0500, Jeffrey Hutzelman wrote:
On Thursday, March 30, 2006 06:08:10 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
Huh? Why should UIDs not conflict with PAGs? What am I missing?
Because AFS identifies credentials, cached connections, and cached
On Thu, Mar 30, 2006 at 09:12:50PM -0500, Jeffrey Hutzelman wrote:
On Thursday, March 30, 2006 07:41:05 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
No, the kernel doesn't need PAGs for itself -- it upcalls to daemons
that do (e.g., gssd(1M)) and which can use door_ucred(3DOOR)
[EMAIL PROTECTED] (Douglas E. Engert) writes:
On Solaris 10, the Solaris ssh and sshd work pretty well with the Solaris 10
Kerberos. We can even get them to get AFS tokens.
Solaris 9 is a different story. We use The MIT Kerberos and OpenSSH.
I believe most of Solaris 10 SSH is now backported
On Wed, Mar 29, 2006 at 09:03:03AM +, Casper H.S. Dik wrote:
[EMAIL PROTECTED] (Douglas E. Engert) writes:
On Solaris 10, the Solaris ssh and sshd work pretty well with the Solaris 10
Kerberos. We can even get them to get AFS tokens.
Solaris 9 is a different story. We use The MIT
4) /etc/krb5/krb5.conf is the standard one from campus and includes:
default_tgs_enctypes = des-cbc-crc
default_tkt_enctypes = des-cbc-crc
You may want to take these last two likes out, as it might be forcing to
only accept DES, even though the KDC and the client think it can do
Casper H.S. Dik wrote:
[EMAIL PROTECTED] (Douglas E. Engert) writes:
On Solaris 10, the Solaris ssh and sshd work pretty well with the Solaris 10
Kerberos. We can even get them to get AFS tokens.
Solaris 9 is a different story. We use The MIT Kerberos and OpenSSH.
I believe most
On Tue, Mar 28, 2006 at 09:09:05PM -0800, Russ Allbery wrote:
Nicolas Williams [EMAIL PROTECTED] writes:
Just because your principals only have 1DES long-term keys doesn't mean
that you need to set default_tgs_enctypes/default_tkt_enctypes; in fact,
you shouldn't.
Oh, I agree! I'm
On Wed, Mar 29, 2006 at 10:02:54AM -0600, Douglas E. Engert wrote:
If you really wanted to get this to work better, add a parameter
on to your pam_krb5 to support this, and have it set the KRB5CCNAME.
Suggestion noted.
Another problem is that only the gssapi is exposed, and not the
On Wed, Mar 29, 2006 at 03:24:24PM -0600, Will Fiveash wrote:
On Wed, Mar 29, 2006 at 10:02:54AM -0600, Douglas E. Engert wrote:
If you really wanted to get this to work better, add a parameter
on to your pam_krb5 to support this, and have it set the KRB5CCNAME.
Suggestion noted.
Sure,
Nicolas Williams wrote:
On Wed, Mar 29, 2006 at 03:24:24PM -0600, Will Fiveash wrote:
On Wed, Mar 29, 2006 at 10:02:54AM -0600, Douglas E. Engert wrote:
If you really wanted to get this to work better, add a parameter
on to your pam_krb5 to support this, and have it set the KRB5CCNAME.
On Wed, Mar 29, 2006 at 03:53:33PM -0600, Douglas E. Engert wrote:
Nicolas Williams wrote:
On Wed, Mar 29, 2006 at 03:24:24PM -0600, Will Fiveash wrote:
On Wed, Mar 29, 2006 at 10:02:54AM -0600, Douglas E. Engert wrote:
If you really wanted to get this to work better, add a parameter
Ken Hornstein [EMAIL PROTECTED] writes:
As someone who spent years tracking down problems related to those damn
lines in krb5.conf trust me when I say that you want to start
removing those configuration options _now_.
Yeah, believe me, I know.
Cruise ship, momentum, small wheel, etc.
Fletcher Cocquyt wrote:
Hi,
I am attempting to get our Solaris 9 and 10 servers to use campus kdc for ssh
authentication.
I want to end up with a cookbook of step by step instructions on how to
convert a fresh install of Solaris to kerberized ssh.
Currently I am trying to make
Douglas E Engert [EMAIL PROTECTED] writes:
5 host/[EMAIL PROTECTED] (DES cbc mode with CRC-32)
Realms are usually uppercase. Is this the correct principal?
Yes.
How did you create this keytab file?
Using our normal keytab creation mechanism.
4) /etc/krb5/krb5.conf is the standard
On Tue, Mar 28, 2006 at 03:50:12PM -0600, Douglas E. Engert wrote:
Fletcher Cocquyt wrote:
I have:
1) Placed my krb5.keytab in /etc/krb5/krb5.keytab:
# klist -e -k /etc/krb5/krb5.keytab
Keytab name: FILE:/etc/krb5/krb5.keytab
KVNO Principal
On Tue, Mar 28, 2006 at 07:29:14PM -0800, Russ Allbery wrote:
Douglas E Engert [EMAIL PROTECTED] writes:
4) /etc/krb5/krb5.conf is the standard one from campus and includes:
default_tgs_enctypes = des-cbc-crc
default_tkt_enctypes = des-cbc-crc
You may want to take these last
Nicolas Williams [EMAIL PROTECTED] writes:
Just because your principals only have 1DES long-term keys doesn't mean
that you need to set default_tgs_enctypes/default_tkt_enctypes; in fact,
you shouldn't.
Oh, I agree! I'm just saying that it's not going to help to change that.
Besides this
Nicolas Williams [EMAIL PROTECTED] writes:
Can you send kadmin(1) getprinc output for the host's host principal?
Expiration date: [never]
Last password change: Mon Mar 27 16:57:25 PST 2006
Password expiration date: [none]
Maximum ticket life: 1 day 01:00:00
Maximum renewable life: 7 days
56 matches
Mail list logo
