If I ssh to the windows host as "userA", then run klist, I see the
following:
(as userA - krbcc32s NOT running)
$ klist
klist.exe: No credentials cache found (ticket cache API:krb5cc)
That's as expected. And... looking at ProcessExplorer, the krbcc32s
process is now running as "userA".
Now, ssh as "userB" and run klist:
(as userB - krbcc32s running as userA)
$ klist
klist.exe: Credentials cache I/O operation failed XXX while getting default ccache
If I kill krbcc32s and redo the test, but login as "userB" first, I see
just the reverse, ie:
(as userB - krbcc32s NOT running)
$ klist
klist.exe: No credentials cache found (ticket cache API:krb5cc)
(as userA - krbcc32s running as userB)
$ klist
klist.exe: Credentials cache I/O operation failed XXX while getting default ccache
My first suspicion was the fact that the CC is the same for both users
(API:krb5cc), but if I redo the above tests and set KRB5CCNAME to
something unique for each user (eg. API:krb5cc_userA, API:krb5cc_userB) it
fails the same way.
If I use a unique "FILE:" credentials cache for each user (eg.
FILE:C:/tmp/krb5cc_userA, FILE:C:/tmp/krb5cc_userB), then it seems to
work, but krb5cc32s is running as the first user who started it, which
bothers me.
Soooo... 2 questions:
1) Is is not possible to use an API: credentials cache for more then one
user?
2) Is it OK to use a FILE: credentials cache in this case even though
krb5cc32s is running as the first user who started it?
Is that a problem? Is there some reason not to rely on this?
FYI... with regards to SSHD creating a new logon session for each user,
apparently this is a Cygwin issue. I'm using Cygwin OpenSSH (5.1) and if
I login via password authentication I do get a new session for each user.
If I use pubkey authentication it uses the same session as the sshd
process. This problem is supposed to be addressed in the forthcoming
Cygwin 1.7 release.
http://marc.info/?l=openssh-unix-dev&m=125784677826016&w=2
On Mon, 9 Nov 2009, Jeffrey Altman wrote:
> krbcc32s.exe is per session. You can't run two instances in the same
> session with different authentication contexts. I don't know how the
> sshd you are using is implemented but apparently it doesn't run the
> underlying users in distinct logon sessions.
>> ________________________________________________
>> Kerberos mailing list Kerb...@mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>