Bug 154977

So if you already know it: Is this a problem with sshd or PAM?

It is in PAM. See the Debian bug report.

Marc, as a bugreporter it is generally your responsibility to provide the necessary information about the problem. Pointing to external sources is no good idea and does not strengthen your credibility. You have already read about this problem and it would make you little trouble to point it out more exactly, this spares us the work to do so and speeds up the process. Have that in mind next time.

Sorry if I did something wrong, but I'm not sure what exactly you expect me to do.

I don't know any more about the causes of the bug than what is stated in the external bug report. So I thought it best to just point to it as a reference, and also because it says, that there already exists a patch, which I thought helpful.

However, I experienced the bug myself, and only later found out that someone else had this exact same problem; so I'm not copying bug reports from other bugzillas, if that's what you meant by "does not strengthen your credibility".

I'm confused now...

A question:

You login vial ssh with username and password, _not_ via gssapi.
Your server has pam_krb5 configured. 
You can successfully log-in, but you do not have a ticket.( klist shows nothing)

Is this correct?

If this is correct it could be an openssh problem. 

Yes privileged separation has implementation problems, when something was made in child and session lives in parent and that it is problem, I think openssh developers will rewrite it in the future (they are knou about it). I read debian bugreport and debian workaround by fix in pam_krb5:
"Always use a disk cache for temporary storage of credentials and cope
 with not having module-specific data during pam_sm_setcred by passing
 the cache path in an environment variable.  This is required to cope
 with OpenSSH's technique (when using ChallengeResponseAuthentication)
 of doing PAM authentication in a child process and then opening the
 session in the parent.  (Closes: #339734) "

I also found out that in session.c function do_setusercontext() 
always do_pam_setcred(0); is called. "0" means "reinitializing credentials"
which is not possible without an existing ticket. 

But also calling it with "1" did not work. It seems the stash got lost,
which could be the problem of Comment #6.

(In reply to comment #5)
> A question:
> 
> You login vial ssh with username and password, _not_ via gssapi.
> Your server has pam_krb5 configured. 
> You can successfully log-in, but you do not have a ticket.( klist shows
> nothing)
> 
> Is this correct?
> 

Yes, this is correct.

> If this is correct it could be an openssh problem. 
> 

Petr Ostadal already commented on this in comment #6; I should have written in comment #2:

The cause of the problem is in SSH, but it can be fixed (or worked around) in PAM.

Ok, who will take over the bug openssh or pam_krb5 ?

I think openssh.

We cannot comare with the debian module, because they use a complete different pam_krb5 module.

We have two problems:

ssh calles pam_setcred(sshpam_handle, PAM_REINITIALIZE_CRED); 
This cannot work, if no ticket is there.

It passes the wrong enviroment. The stash got lost, the ticket from auth was not present in the session. 

But I think this is no major bug. 
What would happen if you add your ssh-key to authorized_keys? 
You have to call kinit for you own, because in this case pam is not involved.
To get a ticket in case of pam auth, would be a nice feature, but it is not a major bug :-)

JFYI: There is a solution to get a ticket after ssh login. But you have to configure it by hand.

See Bug #156541

I investigated in SuSE 10.0 and found the following:
- /etc/krb5.conf -> appdefaults -> pam: 
   external=sshd
   use_shmem=sshd
  enables full ticket passing.
- But only, if /etc/pam.d/common-auth contains
   session  optional pam_krb5 
  (adding 'debug' here gives helpful info in /var/log/messages)

The second item is not taken care of by yast. See #156541

*** Bug 156541 has been marked as a duplicate of this bug. ***

Bug #156541 still seems valid in 10.1
In fact more valid than this one.

Please consider: ssh needs the password in session-stage of pam_krb5 to generate a ticket. Thats not a bug in ssh; its simply a necessity of kerberos with pam.
Anyone else?

(In reply to comment #12)
> I investigated in SuSE 10.0 and found the following:
> - /etc/krb5.conf -> appdefaults -> pam: 
>    external=sshd
>    use_shmem=sshd
>   enables full ticket passing.
> - But only, if /etc/pam.d/common-auth contains
>    session  optional pam_krb5 
>   (adding 'debug' here gives helpful info in /var/log/messages)
> 
> The second item is not taken care of by yast. See #156541
> 

I tested you suggestion with 10.1b8. It works, but only if you add "session optional pam_krb5.so" (note the .so) to common-session, not common-auth.

Marc,

you are absolutely right. 
I must have mixed it up while writing the above comment. Thanks for
pointing this out.

Is fixed for openSUSE 10.2 . 

Ok, I close it as wontfix (for 10.1).