similar to: [Bug 757] KRB5CCNAME inherited from root's environment under AIX

http://bugzilla.mindrot.org/show_bug.cgi?id=757 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #498 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2003-12-23 00:44 -------

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

Does anyone see a need for a patch that allows Kerberos password authentication with the correct local options? I'm simply trying to get a feel for if it's worth my time to investigate it further. The issue is that we also use a patch that does Kerberos ticket passing and our ticket lifetime is slightly higher than the default 10 hours. Users experience different behavior when they

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

openssh-unix-dev at mindrot.org kerberos at ncsa.uiuc.edu We believe there is a security flaw in either OpenSSH and/or RedHat's pam_krb5 module. When a Kerberos principal has the REQUIRES_PWCHANGE (+needchange) flag set, OpenSSH+pam_krb5 will still successfully authenticate the user. Local 'su' and 'login' fail in this case which leads us to believe it's at least

http://bugzilla.mindrot.org/show_bug.cgi?id=757 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From dtucker at zip.com.au 2004-02-06

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, I've been doing some extensive troubleshooting with respect to some issues mounting CIFS shares on a Windows box via Kerberos. We're using the command: /sbin/mount.cifs //whatever/whatever /whatever -o sec=krb5i This should mount the share using Kerberos & Packet-signing by using the cached credentials of the user executing the command. With judicious use of strace, it

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

Small respin of the patches that I posted a few days ago. The main difference is the reordering of the series to make it do the group and grouplist manipulation first, and then the patch that makes it grab the KRB5CCNAME from the initiating process. I think the code is sound, my main question is whether we really need the command-line switch for this. Should this just be the default mode of

http://bugzilla.mindrot.org/show_bug.cgi?id=372 Summary: [authkrb5] : KRB5CCNAME set to pointer Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: basalt

I'm using a OpenSSH 3.0.2p1 with the krb5 patch from <http://www.sxw.org.uk/computing/patches/openssh.html>. I'm getting KRB5CCNAME set to "" even though <http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=98269278629018&w=2> mentions fixing it. This causes things like kinit to fail with a somewhat uninformative error message. The relevant sshd_config lines

http://bugzilla.mindrot.org/show_bug.cgi?id=372 basalt at easynet.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement Summary|[authkrb5] : KRB5CCNAME set |[RFE] [authkrb5] : |to pointer |KRB5CCNAME

On Mon, 2017-02-13 at 05:02 -0500, Simo Sorce wrote: > On Sat, 2017-02-11 at 10:16 -0500, Jeff Layton wrote: > > On Sat, 2017-02-11 at 08:41 -0500, Jeff Layton wrote: > > > 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: > > >

> > 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

http://bugzilla.mindrot.org/show_bug.cgi?id=372 ------- Additional Comments From simon at sxw.org.uk 2003-05-21 00:45 ------- If this is reproducable, then its a bug somewhere. Could you confirm which Kerberos library and version you've seen this problem with? Are the credentials correctly created in /tmp, and KRB5CCNAME just isn't set right, or are the credentials not being

http://bugzilla.mindrot.org/show_bug.cgi?id=698 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |793 nThis| | Summary|Specify FILE: for credential|Specify FILE: for KRB5CCNAME

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

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