similar to: [ GSSAPI ] Environment settings

http://bugzilla.mindrot.org/show_bug.cgi?id=751 Summary: KRB5CCNAME set incorrectly in GSSAPI code Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Kerberos support AssignedTo: openssh-bugs at mindrot.org

Hello All, I have run into a situation where a user exiting from a PAM_KERBEROS-authenticated session runs the risk of deleting a kinit-generated credentials file that was already sitting on the server. I will explain the problem in detail, but let me begin with my question. It has a specific reference to PAM_KERBEROS, but it can also be a general question. If a user (ssh) session was

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 either obtained via GSSAPI delegation, PAM or other kerberos login code in the sshd. The above two

I believe there is a bug in how AIX handles the KRB5CCNAME environment variable. The symptom occurs when a root user restarts sshd while they have KRB5CCNAME set; all of the resulting client connections will inherit the same KRB5CCNAME variable. This can occur if the admin uses 'ksu' or some other kerberized method of obtaining root privileges. Investigating this problem, I stumbled

Hello, I am using OpenSSH-3.8p1 on HP-UX machine with USE_POSIX_THREADS option. This is for making the kerberos credentials file to be created in the system with PAM. In OpenSSH versions 3.5 when authentication is done with pam kerberos, a /tmp/krb5cc_X_Y file is created on the server side. But the KRB5CCNAME variable is not set by default. So, after we manually set this environment variable, the

Hello, I have a Dovecot 2.2.25 set up with OpenLDAP back end. I was trying to set up a GSSAPI Kerberos authentication with the LDAP server but with little success. Seems no matter what I try I end up with the following error message: dovecot: auth: Error: LDAP: binding failed (dn (imap/host.example.com at EXAMPLE.COM)): Local error, SASL(-1): generic failure: GSSAPI Error: Unspecified GSS

On 2016-10-11 10:00, Aki Tuomi wrote: > On 11.10.2016 10:43, Juha Koho wrote: >> >> On 2016-10-11 09:18, Aki Tuomi wrote: >>> On 11.10.2016 10:13, Juha Koho wrote: >>>> Hello, >>>> >>>> I have a Dovecot 2.2.25 set up with OpenLDAP back end. I was trying >>>> to >>>> set up a GSSAPI Kerberos authentication with

https://bugzilla.mindrot.org/show_bug.cgi?id=2815 Bug ID: 2815 Summary: please set KRB5CCNAME to collection Product: Portable OpenSSH Version: 7.4p1 Hardware: amd64 OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: Kerberos support Assignee: unassigned-bugs

I?ve stumbled across a rather obscure problem with ssh. My machine is setup to use Kerberos authentication, i.e., I use the pam_krb5 module in the ssh auth section of the PAM configuration file and I have sshd compiled to accept valid Kerberos 5 tickets as well. I also use OpenAFS, so I?ve got the pam_openafs_session module in the ssh session section of the PAM configuration file. Everything

On 2016-10-11 09:18, Aki Tuomi wrote: > On 11.10.2016 10:13, Juha Koho wrote: >> Hello, >> >> I have a Dovecot 2.2.25 set up with OpenLDAP back end. I was trying to >> set up a GSSAPI Kerberos authentication with the LDAP server but with >> little success. Seems no matter what I try I end up with the following >> error message: >> >> dovecot:

> > I should have mentioned this earlier, but the users does not exist > > in /etc/passwd, instead they are in LDAP and when they log in to the > > computer they get some Kerberos tickets for the domain and the file > > system. When printing on 14.04 they get another Kerberos ticket for > > the printing system according to "klist" after they have done

I have found the following patches to be desirable for using sshd on a Tru64 UNIX system with the Kerberos 5 SIA module (libsia_krb5.so) from Heimdal. These patches do the following: 1) preserve context between the password authentication and the session setup phases. This is necessary because the Heimdal SIA module stores Kerberos context information as mechanism-specific data in

http://bugzilla.mindrot.org/show_bug.cgi?id=757 Summary: KRB5CCNAME inherited from root's environment under AIX Product: Portable OpenSSH Version: -current Platform: PPC OS/Version: AIX Status: NEW Severity: minor Priority: P2 Component: sshd AssignedTo: openssh-bugs at mindrot.org

Chad reported that he was seeing a regression in cifs-utils-6.6. Prior to that, cifs.upcall was able to find credcaches in non-default FILE: locations, but with the rework of that code, that ability was lost. Unfortunately, the krb5 library design doesn't really take into account the fact that we might need to find a credcache in a process that isn't descended from the session. When the

Thank you both for the replies and explanation! @douglas Can i set?KRB5CCNAME somewhere so that it uses /home? Where? But even if i could set the env variable i have this odd behavior: I now have 4 vms running. 2 are rocky8 and 2 are rocky9, with same settings and versions I stated on my first post. From the 4 vms, when I ssh into them, 2 of them set a cache file in the users home and the

Here is a patch I just wrote and tested which may be of interest to those who wish to use KerberosGetAFSToken (currently requires Heimdal libkafs) in combination with GSSAPIDelegateCredentials. The patch is in the public domain and comes with no warranty whatsoever. Applies to pristine 3.8p1. Works for me on Solaris and Tru64. I'd probably have used Doug Engert's patch from 2004-01-30 if

On 2016-10-11 11:03, Aki Tuomi wrote: > On 11.10.2016 11:56, Juha Koho wrote: >> >> On 2016-10-11 10:00, Aki Tuomi wrote: >>> On 11.10.2016 10:43, Juha Koho wrote: >>>> >>>> On 2016-10-11 09:18, Aki Tuomi wrote: >>>>> On 11.10.2016 10:13, Juha Koho wrote: >>>>>> Hello, >>>>>>

On 6/6/2024 8:26 AM, Dave Macias wrote: > *I wanted to see if I could make the cache file user-specific, instead of > the default location (/tmp/krb5cc-blabla).* SSH is creating a separate ticket cache file for each login session and owned by the user. This has been the preferred way to do this for decades. https://kerberos.mit.narkive.com/YJB4Hshz/krb5ccname-and-sshd Your: "Ticket

Just to show what i mean when i ssh into my vms, 2 vms save the cache in /tmp and the other 2 in /home. See what happens when i run the loop below: > for i in rocky8client rocky9client rocky9server rocky8server; do /usr/bin/sshpass -p password /usr/bin/ssh -l jdoe $i "hostname; klist"; done rocky8client.domain.net Ticket cache: FILE:/tmp/krb5cc_2000_WP04h8h0sa Default

I have not looked at Kerberos is years. But it looks like KRB5CCNAME comes from: https://github.com/openssh/openssh-portable/blob/master/gss-serv-krb5.c#L134-L197 But it depends on which version of Kerberos you have, and if you are also use PAM. Google for: heimdal kerberos cache name It looks like there is now a SSSD Kerberos Cache Manager rather then storing in individual file. On 6/11/2024