similar to: [PATCH] Simplify Kerberos credentials cache code

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

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

this is the proposed gssapi diff against OpenSSH-current (non-portable). note: if this goes in, the old krb5 auth (ssh.com compatible) will be removed. please comment. jakob Index: auth.h =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/auth.h,v retrieving revision 1.1.1.2 retrieving revision 1.3 diff -u -r1.1.1.2 -r1.3 --- auth.h

Hi All. I'm looking for some help to merge an outstanding Kerberos credential cache change from OpenBSD into Portable. I don't know enough about Kerberos to figure out how that change should be applied for the non-Heimdal(?) code path. The outstanding diff is attached. Any volunteers? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4

If I am trying to build OpenSSH 6.6 with Kerberos GSSAPI support, do I still need to get Simon Wilkinson's patches? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 |

On Fri, 2017-02-10 at 15:14 -0500, Simo Sorce wrote: > On Fri, 2017-02-10 at 14:29 -0500, Jeff Layton wrote: > > On Fri, 2017-02-10 at 14:14 -0500, Simo Sorce wrote: > > > On Fri, 2017-02-10 at 13:30 -0500, Jeff Layton wrote: > > > > On Fri, 2017-02-10 at 12:39 -0500, Jeff Layton wrote: > > > > > On Fri, 2017-02-10 at 11:15 -0600, Chad William Seys

On Thu, 2017-02-09 at 14:45 -0600, Chad William Seys wrote: > Hi Jeff, > Could you look at the following mailing list posting? > > https://lists.samba.org/archive/samba/2017-February/206468.html > > It looks like cifs.upcall has changed its behavior. As described in > that post, I can mount with root / kerberos, but then cannot access with > another user who has

On Fri, 2017-02-10 at 11:15 -0600, Chad William Seys wrote: > Hi Jeff, > > > So we have a default credcache for the user for whom we are operating > > as, but we can't get the default principal name from it. My guess is > > that it's not finding the > > This mount is run by root UID=0 and seems to be find that credential > cache without problem (earlier

If you like running QEMU as a normal user (very common for TCG runs) but you have to run virtiofsd as a root user you run into connection problems. Adding support for an optional --socket-group allows the users to keep using the command line. Signed-off-by: Alex Benn?e <alex.bennee at linaro.org> Reviewed-by: Stefan Hajnoczi <stefanha at redhat.com> --- v1 - tweak documentation and

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

As far as I know this patch has no security implications -- I don't believe that allowing sshd to use get_local_name() (in canohost.c) on a connected socket to determine it's own fqdn will allow a malicious client (or router or dns server) to make it come to the wrong conclusion. But please let me know if you think I'm wrong. Please also let me know if you're just not interested

There are at least three cases: * Linux: check credentials and pid from client; restrict permissions from server * BSD: check credentials only from client; restrict permissions from server * Solaris: wide open --- configure.in | 4 ++-- src/control.c | 11 ++++++++++- src/control_common.h | 1 + src/tincctl.c | 38 ++++++++++++++++++++++++++++++++++---- 4

There is a race in the setup of the ControlMaster socket in auto mode, as illustrated by the following command line: ssh -oControlMaster=auto -oControlPath=sock localhost 'sleep 1; echo 1' & ssh -oControlMaster=auto -oControlPath=sock localhost 'sleep 2; echo 2' & Both of the commands will try to start up as a control client, find that sock does not exist, and switch into

Time for a new cifs-utils release! The main change in this release is a set of cleanups to cifs.upcall to make it more efficient and work better with alternate style credcaches. No longer does it blithely stumble around in /tmp looking for credcaches. We now just use the default credcache that to which the krb5.conf points. Go forth and download!

On 09.07.20 11:06, basti via samba wrote: > There must be a way to cache login infos between reboot. > > sssd or somethink like that? sssd can do it, but windbind's own cache should work just as well. But yes, network-online.target is counterproductive here. > the krb5_ccache file is saved on /tmp/ is there a way to save that to an > other folder, thats not cleanup on

If the rsyncd.conf has a line such as: log file = /var/log/rsync/log and /var/log/rsync doesn't exist or isn't a directory (or the log file can't be opened for any other reason), then there's no warning whatsoever, as rsync forks itself into the background before checking the config, opening the log file, etc. Worse still, it gets a SIGSEGV, and dumps core. Here's a strace

Hi Jeff, Could you look at the following mailing list posting? https://lists.samba.org/archive/samba/2017-February/206468.html It looks like cifs.upcall has changed its behavior. As described in that post, I can mount with root / kerberos, but then cannot access with another user who has credentials. The logs indicate that cifs.upcall cannot find the kerberos ticket for the non-root user.

Signed-off-by: Johannes L?thberg <johannes at kyriasis.com> --- gss-serv-krb5.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/gss-serv-krb5.c b/gss-serv-krb5.c index 795992d9..a12bb244 100644 --- a/gss-serv-krb5.c +++ b/gss-serv-krb5.c @@ -106,6 +106,11 @@ ssh_gssapi_krb5_userok(ssh_gssapi_client *client, char *name) } else retval = 0; +#ifdef USE_PAM + if

As you know, revoking RSA/DSA keys in an SSH environment requires editing all authorized_keys and authorized_keys2 files that reference those public keys. This is, well, difficult at best but certainly very obnoxious, particularly in a large environment. SSH key management is difficult. This patch simplifies key management wherever GSS-API/Kerberos is used and is general enough to be used with

On 09.07.20 10:29, L.P.H. van Belle via samba wrote: > Hai Basti, > >> -----Oorspronkelijk bericht----- >> Van: samba [mailto:samba-bounces at lists.samba.org] Namens >> basti via samba >> Verzonden: donderdag 9 juli 2020 10:20 >> Aan: samba at lists.samba.org >> Onderwerp: [Samba] AD Users on Linux Laptop >> >> Hello, >> I have setup