Hi Stephan,
since Redhat has removed the support for DES/DES3 enctypes completely in
RHEL8.3 (and newer) and your client is still using it (I can see it in
your provided log: (enctype=1)|(enctype=2)|(enctype=3)) it will fail.
RHEL8.3 and newer: completely removed support for DES and DES3
Hi Jeffrey,
Thanks for having a look at the problem.
However, I obviously did not do a very good job detailing exactly what
we did ... so here's my next try. Warning: It is going to be lengthy :-)
First off: We do not use SSSD. And we would like to keep it that way,
since it caused
Not surprised that they patched something useful in. And it is a useful
option.
thanks
On Mon, Jul 11, 2022 at 12:40:57PM -0700, Carson Gaspar wrote:
> This is a Red Hat patch: openssh-7.7p1-gssapi-new-unique.patch
>
> On 7/11/2022 12:26 PM, Dirk Heinrichs wrote:
> > Dave Botsch:
> >
> > >
This is a Red Hat patch: openssh-7.7p1-gssapi-new-unique.patch
On 7/11/2022 12:26 PM, Dirk Heinrichs wrote:
Dave Botsch:
Maybe it's not in newer release of openssh?
Nope. Also looked up Debian Stretch's man page for OpenSSH 7.9. Doesn't
have it. See
Yup, I see that that option is not there on rhel6 with
openssh-server-5.3p1-124.el6_10.x86_64
so must be a new option. And something that was clearly handled
differently on RHEL6.
thanks!
On Mon, Jul 11, 2022 at 09:26:54PM +0200, Dirk Heinrichs wrote:
> Dave Botsch:
>
> > Maybe it's not in
Dave Botsch:
> Maybe it's not in newer release of openssh?
Nope. Also looked up Debian Stretch's man page for OpenSSH 7.9. Doesn't
have it. See
https://manpages.debian.org/stretch/openssh-server/sshd_config.5.en.html
Bye...
Dirk
--
Dirk Heinrichs
Matrix-Adresse: @heini:chat.altum.de
GPG
Maybe it's not in newer release of openssh?
RHEL8 is using:
$ rpm -q openssh-server
openssh-server-8.0p1-13.el8.x86_64
And from the man page:
KerberosUniqueCCache
Specifies whether to store the acquired tickets in the
per-session credential cache under /tmp/ or
Dave Botsch:
> KerberosUniqueCCache=yes in sshd.conf
Could you elaborate on what this option is good for? I can't find it in
sshd_config(5), neither on a Debian Bookworm system with OpenSSH 9.0,
nor in online man-pages of Arch Linux or upstream OpenSSH. Is this some
special RH-only thing?
Since we are not using PAGs anymore on most of our systems and instead
using UID based logins for tokens, I should retest and see what does and
doesn't work with keyrings as I honestly don't recall at this point, and
things have changed with the various point releases of RHEL8. One of the
We went back to using FILE based caches for use along with PAGs.
Something didn't work right with keyring caches, and I don't recall
what.
I believe our general path was, keyring didn't work, ok, go to file
based. Now get sssd and pam_afs_session working properly and work around
the krb5-1.18
I think all we had to do, actually, was set appropriate options for
GSSAPI in sshd_config ... and make sure it was still using PAM for the
account and session pieces.
We did not have to use any stashcred or chuse stuff... our session stack
looks like:
session optional
Hi all!
Jeffrey pointed us in the right direction - and most useful, a reason
why it failed for us. Kudos to Jeffrey, as always!
Since we won't touch SSSD with a 10-yard-stick, we gave
pam_afs_session.so a spin. And lo and behold: It really worked!
We have the following in our
In our case, we use multiple kerberos domains to authenticate users.
So in pam.d/password-auth...
authsufficient pam_sss.so
forward_pass
then lets sssd take care of figuring out via an ldap lookup, which
kerberos domain to authenticate the user
I wanted to mention that we are successfully doing ssh and gnome-shell
logins with pam_sssd where sssd takes care of authN via kerberos and via
ldap provides group information, and pam_afs_session to get afs tokens.
Two difficulties... if using PAGSHs, not all processes run inside a
pagsh, which
reply inline
On 7/11/2022 4:30 AM, Stephan Wonczak (a0...@rrz.uni-koeln.de) wrote:
Hi Jeffrey,
Thanks for having a look at the problem.
However, I obviously did not do a very good job detailing exactly
what we did ... so here's my next try. Warning: It is going to be
lengthy :-)
First
(resend without attachment - original Mail did not make it to the
list!)
Hi Jeffrey,
Thanks for having a look at the problem.
However, I obviously did not do a very good job detailing exactly what
we did ... so here's my next try. Warning: It is going to be lengthy :-)
First
On 7/8/2022 6:57 AM, Jeffrey E Altman wrote:
Use of the RHEL7 pam_krb5 on a sssd enabled system will do the wrong
thing since its going to step on the toes of sssd's Kerberos ticket
processing.
Only if you let sssd touch Kerberos. There are any number of reasons not
to let it do so (no
Jeffrey E Altman:
> Red Hat's pam_krb5 is not shipped nor supported for RHEL8 (or later).
Ah, OK. As a non-RH user, I wasn't aware they threw it out. Thanks for
clarifying.
> The replacement is sssd which supports Kerberos ticket acquisition but
> not AFS token acquisition. The recommendation
Stephan Wonczak:
> Any advice would be greatly appreciated!
As Benjamin wrote: Try pam_afs_session. Should be added to the "auth"
and "session" blocks of your PAM setup.
https://packages.debian.org/bullseye/libpam-afs-session
https://www.eyrie.org/~eagle/software/pam-afs-session
HTH...
Sounds like the version of pam_krb5 you are attempting to build does not
include support for rxkad-kdf.
https://lists.openafs.org/pipermail/afs3-standardization/2013-July/002738.html
The version of pam_krb5 that supports rxkad-kdf contains a
minikafs_kd_derive() function at minikafs.c line
On 7/7/2022 1:04 PM, Dirk Heinrichs (dirk.heinri...@altum.de) wrote:
Benjamin Kaduk:
Are you aware of pam_afs_session
(https://github.com/rra/pam-afs-session)? Without knowing more about
what you're using pam_krb5 for it's hard to make specific suggestions
about what alternatives might exist.
Hi everyone!
(Berthold's colleague here)
We dug a little deeper and found the part in the pam_krb5-sources where
it fails. It is in the file "minikafs.c" starting in line 775. It looks
like the call to krb5_get_credentials() gets a non-zero return value, thus
making it bail out.
The
Am 08.07.22 um 11:24 schrieb Berthold Cogel:
We're using the pam_krb5 shipped with Red Hat.
I've rebuild the module from the RHEL 7 source rpm on RHEL 8. And it
seems to work for some value of working
Supported enctypes in our kdc:
aes256-cts-hmac-sha1-96:normal des-cbc-crc:normal
Am 07.07.22 um 19:04 schrieb Dirk Heinrichs:
Benjamin Kaduk:
Are you aware of pam_afs_session
(https://github.com/rra/pam-afs-session)? Without knowing more about
what you're using pam_krb5 for it's hard to make specific suggestions
about what alternatives might exist.
BTW: pam_krb5 !=
Benjamin Kaduk:
> Are you aware of pam_afs_session
> (https://github.com/rra/pam-afs-session)? Without knowing more about
> what you're using pam_krb5 for it's hard to make specific suggestions
> about what alternatives might exist.
BTW: pam_krb5 != pam_krb5. There are two different modules with
On Wed, Jun 29, 2022 at 04:02:17PM +0200, Berthold Cogel wrote:
> Hello,
>
> we're trying to prepare our environment for the migration to RHEL 8.
>
> At the moment, with RHEL 7 we still have our user homes in AFS and use
> pam_krb5 to get a token at login. In the long term we will migrate our
26 matches
Mail list logo
