https://bugzilla.redhat.com/show_bug.cgi?id=2325893
Bug ID: 2325893
Summary: sssd gpo_child doesn't have sufficient rights to
populate GPO policies
Product: Fedora
Version: 41
Hardware: x86_64
OS: Linux
Status: NEW
Component: sssd
Keywords: CommonBugs, Desktop
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: nekopilot(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, mzidek(a)redhat.com,
pbrezina(a)redhat.com, sbose(a)redhat.com,
ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
# 1. Issue
After upgrade from F39 to F41 via UI path the login to the system with AD
account is not possible. Local account works well.
# 2. Workaround
sssd service works under sssd user in Fedora 41. The folder with GPO policies
has wrong rights with owner root:
ls -lah /var/lib/sss/gpo_cache/example.com/Policies/
total 0
drwx------. 4 root root 98 Jan 10 2024 .
drwx------. 3 sssd sssd 22 Jan 10 2024 ..
drwx------. 3 root root 36 Nov 13 07:33 {31B2F332-016D-11D2-945F-00C04FBB84F9}
drwx------. 3 root root 36 Nov 13 07:33 {7E50761D-1E4D-4D2B-BD86-E667EED3DF1E}
It is possible to change the owner of the directories. After that the login
with AD account works well.
chown -R sssd:sssd /var/lib/sss/gpo_cache
Reproducible: Always
Steps to Reproduce:
1. Your F39 system must be joined to AD with sssd and you can login to the
system with AD account.
2. Upgrade from F39 to F41.
3. Try to login with AD account.
Actual Results:
Login from Gnome UI is not possible with error: "Wrong user name or password".
Expected Results:
You can login to the system with AD account.
Your F39 system must be joined to AD with sssd and you can login to the system
with AD account.
After upgrade you can't login from UI with AD account but:
1. kinit user.name(a)example.com - works well.
1. id user.name(a)example.com - works well.
1. realm list - looks good.
In logs you can find error message:
cat /var/log/sssd/gpo_child.log
```
[gpo_child[4066]] [prepare_gpo_cache] (0x0020): [RID#23]
mkdir(/var/lib/sss/gpo_cache/example.com/Policies/{31B2F332-016D-11D2-945F-…
failed: 13
```
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2325893
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2319608
Bug ID: 2319608
Summary: python3-sssdconfig packs outdated .pyc files
Product: Fedora
Version: rawhide
OS: Linux
Status: NEW
Component: sssd
Keywords: Regression
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: jpazdziora(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, mzidek(a)redhat.com,
pbrezina(a)redhat.com, sbose(a)redhat.com,
ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
The /usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/*.cpython-313.pyc
/usr/lib/files get regenerated when SSSDConfig module is used.
Reproducible: Always
Steps to Reproduce:
1. dnf install -y python3-sssdconfig
2. stat
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
3. python3 -c 'import SSSDConfig'
4. stat
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
Actual Results:
[root@0890eef375bc /]# stat
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
File:
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
Size: 57759 Blocks: 120 IO Block: 4096 regular file
Device: 0,109 Inode: 1226072 Links: 2
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-10-15 00:00:00.000000000 +0000
Modify: 2024-10-15 00:00:00.000000000 +0000
Change: 2024-10-18 09:46:42.433097566 +0000
Birth: 2024-10-18 09:46:42.432097551 +0000
[root@0890eef375bc /]# python3 -c 'import SSSDConfig'
[root@0890eef375bc /]# stat
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
File:
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
Size: 59402 Blocks: 120 IO Block: 4096 regular file
Device: 0,109 Inode: 1196042 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-10-18 09:47:14.646592272 +0000
Modify: 2024-10-18 09:47:14.646592272 +0000
Change: 2024-10-18 09:47:14.646592272 +0000
Birth: 2024-10-18 09:47:14.646592272 +0000
Expected Results:
The Size and Modify time in the second stat run should match the output from
the first one.
First found by
https://github.com/freeipa/freeipa-container/actions/runs/11397511703/job/3….
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2319608
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2334868
Bug ID: 2334868
Summary: updating an existing system to sssd-2.10.1 causes sssd
to fail with permissions issues
Product: Fedora
Version: 41
OS: Linux
Status: NEW
Component: sssd
Keywords: Upgrades
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: roth(a)ursus.net
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, pbrezina(a)redhat.com,
sbose(a)redhat.com, ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
[this is on a ostree system (Fedora 41 Kinoite)]
From what I can tell, the sssd permissions changed recently from root:sssd to
sssd:sssd, and there are subtle differences in the way the config directories
and config files are owned that cause the most recent update to fail.
The previous version (2.10.0) had /etc/sssd at mode 0700, owned by root:sssd.
Now that the service runs as sssd:sssd it is not able to access previous
configs in /etc/sssd and the daemon fails with a permissions error.
There are a couple of contributing factors to this update failure:
1. the three-way merge for /etc files done by ostree does not preserve file
permissions, and does not update directory permissions. When /usr/etc/sssd
changed from 0700 to 0750, this was not reflected in /etc/sssd.
2. the ExecStartPre= statements in sssd.service are a bit optimistic. The chown
and chmod commands don't work with the current service settings (User= and
Group=). They currently fail but this is masked by the '-f' option.
I was able to fix this on my local system by (1) commenting out the
ExecStartPre= statements and (2) moving them to a dependent service that runs
as root. I guess this could also be accomplished with
PermissionsStartOnly=true.
Reproducible: Always
Steps to Reproduce:
1. build up a system that uses sssd (fully-populated /etc/sssd/sssd.conf)
2. stop sssd
3. chmod 0700 /etc/sssd
4. chown root:sssd /etc/sssd
5. try to start sssd
Actual Results:
sssd does not start, it is not able to correctly re-own the files and
directories it needs.
Here is the update report from the most recent ostree transaction
$ rpm-ostree db diff
ostree diff commit from: rollback deployment
(5796a4d9fbff9b2d0e28f34070e6958e0cfb5a1b3ab702fd1ed318ade3aa91ef)
ostree diff commit to: booted deployment
(f07128cd02dc40fbe578714f095140f44e5986f98902783d00bbd837a0ed06d6)
Upgraded:
cldr-emoji-annotation 1:46.1~beta2-1.fc41 -> 1:46.1-1.fc41
cldr-emoji-annotation-dtd 1:46.1~beta2-1.fc41 -> 1:46.1-1.fc41
ibus-typing-booster 2.27.1-1.fc41 -> 2.27.2-1.fc41
intel-vpl-gpu-rt 24.3.4-1.fc41 -> 24.4.4-1.fc41
libsss_certmap 2.10.0-2.fc41 -> 2.10.1-1.fc41
libsss_idmap 2.10.0-2.fc41 -> 2.10.1-1.fc41
libsss_nss_idmap 2.10.0-2.fc41 -> 2.10.1-1.fc41
libsss_sudo 2.10.0-2.fc41 -> 2.10.1-1.fc41
libva-intel-media-driver 24.3.4-1.fc41 -> 24.4.4-1.fc41
libvpl 1:2.13.0-1.fc41 -> 1:2.14.0-1.fc41
libxml2 2.12.8-2.fc41 -> 2.12.9-1.fc41
openjpeg 2.5.3-1.fc41 -> 2.5.3-2.fc41
setup 2.15.0-5.fc41 -> 2.15.0-8.fc41
sssd-client 2.10.0-2.fc41 -> 2.10.1-1.fc41
sssd-common 2.10.0-2.fc41 -> 2.10.1-1.fc41
sssd-kcm 2.10.0-2.fc41 -> 2.10.1-1.fc41
sssd-krb5-common 2.10.0-2.fc41 -> 2.10.1-1.fc41
sssd-ldap 2.10.0-2.fc41 -> 2.10.1-1.fc41
sssd-nfs-idmap 2.10.0-2.fc41 -> 2.10.1-1.fc41
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2334868
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2320042
Bug ID: 2320042
Summary: [abrt] sssd-tools: set_component():
source_files.py:73:set_component:OSError
Product: Fedora
Version: 41
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:a5a6dd78a14a8d86bce922d86636e1cb2da53ec6;VAR
IANT_ID=workstation;
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: maxi(a)maxiicodes.dev
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, mzidek(a)redhat.com,
pbrezina(a)redhat.com, sbose(a)redhat.com,
ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
Version-Release number of selected component:
sssd-tools-2.10.0-1.fc41
Additional info:
reporter: libreport-2.17.15
kernel: 6.11.4-300.fc41.x86_64
cmdline: /usr/bin/python3 -sP /usr/libexec/sssd/sss_analyze error list
cgroup:
0::/user.slice/user-1000.slice/user@1000.service/app.slice/app-cosmic-com.system76.CosmicAppList-3787.scope
uid: 1000
reason: source_files.py:73:set_component:OSError
executable: /usr/libexec/sssd/sss_analyze
type: Python3
package: sssd-tools-2.10.0-1.fc41
runlevel: N 5
exception_type: OSError
crash_function: set_component
interpreter: python3-3.13.0-1.fc41.x86_64
Truncated backtrace:
source_files.py:73:set_component:OSError
Traceback (most recent call last):
File "/usr/libexec/sssd/sss_analyze", line 5, in <module>
sss_analyze.run()
~~~~~~~~~~~~~~~^^
File "/usr/lib/python3.13/site-packages/sssd/sss_analyze.py", line 107, in
run
analyzer.main()
~~~~~~~~~~~~~^^
File "/usr/lib/python3.13/site-packages/sssd/sss_analyze.py", line 102, in
main
args.func(args)
~~~~~~~~~^^^^^^
File "/usr/lib/python3.13/site-packages/sssd/modules/error.py", line 52, in
print_error
source.set_component(component, False)
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.13/site-packages/sssd/source_files.py", line 73, in
set_component
raise IOError
OSError
Local variables in innermost frame:
self: <sssd.source_files.Files object at 0x7f0cd2976e40>
component: <Component.BE: 3>
child: False
domains: []
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2320042
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2334087
Bug ID: 2334087
Summary: Capabilities related changes in
sssd-2.10.1-2.fc42.x86_64 break SSSD in containers
Product: Fedora
Version: rawhide
OS: Linux
Status: NEW
Component: sssd
Keywords: Regression
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: adelton(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, pbrezina(a)redhat.com,
sbose(a)redhat.com, ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
We are running the FreeIPA containers in GitHub Actions of
https://github.com/freeipa/freeipa-container. With sssd 2.10.0-3.fc42 packages
in Fedora rawhide the
https://github.com/freeipa/freeipa-container/actions/runs/12461283683 run
passed, with sssd 2.10.1-2.fc42 the
https://github.com/freeipa/freeipa-container/actions/runs/12489404343 started
to fail for rawhide, on all runtimes.
It is also easy to reproduce the issue locally with
tests/run-partial-tests.sh Dockerfile.fedora-rawhide
In /var/log/sssd/ldap_child.log I then see
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING
BACKTRACE:
* (2024-12-25 16:41:58): [ldap_child[6484]] [sss_log_process_caps]
(0x0100): Starting under ruid=285, euid=285, suid=285 : rgid=284, egid=284,
sgid=284
* (2024-12-25 16:41:58): [ldap_child[6484]] [sss_log_process_caps]
(0x0100): With following capabilities:
(nothing)
* (2024-12-25 16:41:58): [ldap_child[6484]] [main] (0x2000): context
initialized
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000): total
buffer size: 56
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000):
command: Select principal
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000):
realm_str size: 12
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000): got
realm_str: EXAMPLE.TEST
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000):
princ_str size: 16
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000): got
princ_str: ipa.example.test
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000):
keytab_name size: 0
* (2024-12-25 16:41:58): [ldap_child[6484]] [sss_set_cap_effective]
(0x0400): cap_set_proc() failed: 1 ('Operation not permitted')
* (2024-12-25 16:41:58): [ldap_child[6484]] [select_principal_from_keytab]
(0x0200): trying to select the most appropriate principal from keytab
* (2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab]
(0x0020): krb5_kt_start_seq_get failed: Permission denied
********************** BACKTRACE DUMP ENDS HERE
*********************************
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [select_principal_from_keytab]
(0x0010): Failed to read keytab [FILE:/etc/krb5.keytab]: No suitable principal
found in keytab
I see capabilities and file permission related changes in
https://github.com/SSSD/sssd/commits/master/ and in
https://src.fedoraproject.org/rpms/sssd/c/80a939719c9fd4226e7eefc0d3d93c494….
I am able to workaround the issue by reverting the capabilities back to those I
see in sssd 2.10.0-2.fc41, namely
setcap cap_chown,cap_dac_read_search,cap_setgid,cap_setuid=ep
/usr/libexec/sssd/krb5_child
setcap cap_chown,cap_dac_override,cap_setgid,cap_setuid=ep
/usr/libexec/sssd/ldap_child
and putting in /usr/lib/systemd/system/sssd.service.d/capabilities.conf with
[Service]
# In sssd-common-2.10.1-2.fc42.x86_64:
# CapabilityBoundingSet= CAP_SETGID CAP_SETUID CAP_DAC_READ_SEARCH
# In sssd-common-2.10.0-2.fc41.x86_64:
CapabilityBoundingSet= CAP_CHOWN CAP_DAC_OVERRIDE CAP_SETGID CAP_SETUID
CAP_DAC_READ_SEARCH
Things are not proken outside of containers.
So it seems CAP_DAC_READ_SEARCH does not work (is not enough) in containerized
setups.
Reproducible: Always
Steps to Reproduce:
1. git clone https://github.com/freeipa/freeipa-container
2. cd freeipa-container/
3. # to get the state where (a planned) workaround is not present
git checkout d062ba708896d4e0e97d28ac2681097d935cde02
4. # enable a test which does not use the external volume, to minimize impact
of that containerization feature
sed -i 's/^## # test: systemd-container-ipa-server-install.sh/# test:
systemd-container-ipa-server-install.sh/' Dockerfile.fedora-rawhide
5. docker=podman tests/run-partial-tests.sh Dockerfile.fedora-rawhide
Actual Results:
● sssd.service loaded failed failed System Security Services Daemon
Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use
systemd-escape?).
Unit \xe2\x97\x8f.service could not be found.
Yeah, it's not a good error message. It tries to say that sssd.service is
failed.
Expected Results:
No error.
I understand Fedora does not primarily ship SSSD to work in containers, so this
is mostly a headsup that recent changes in the packaging don't seem quite
compatibly with current state of container runtimes.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2334087
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2333529
Bug ID: 2333529
Summary: unpacking of archive failed on file /var/lib/sss/mc:
cpio: chown failed
Product: Fedora
Version: 41
OS: Linux
Status: NEW
Component: sssd
Keywords: Upgrades
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: gregory.lee.bartholomew(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, pbrezina(a)redhat.com,
sbose(a)redhat.com, ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
While trying to upgrade a systemd-nspawn container from Fedora 40 to Fedora 41,
I received the following error:
Upgrading : sssd-common-2.10.0-2.fc41.x86_64
495/1223
error: unpacking of archive failed on file /var/lib/sss/mc: cpio: chown failed
- No data available
The container's /var/lib/sss/mc directory is ro-bind-mounted from the host
system similar to what is described in the last post (dated 11/05/16 14:29)
here:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.…
Reproducible: Always
Steps to Reproduce:
1. dnf upgrade --releasever=41
Actual Results:
Failed:
sssd-common-2.9.5-1.fc40.x86_64
sssd-common-2.10.0-2.fc41.x86_64
Error: Transaction failed
Expected Results:
Transaction succeeded
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2333529
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2305856
Bug ID: 2305856
Summary: sss_ssh_knownhosts man page does not contain
information about replacements
Product: Fedora
Version: rawhide
OS: Linux
Status: NEW
Component: sssd
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: orion(a)nwra.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, mzidek(a)redhat.com,
pbrezina(a)redhat.com, sbose(a)redhat.com,
ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
ssh fails with:
******************************************************************************
Your system is configured to use the obsolete tool sss_ssh_knownhostsproxy.
Please read the sss_ssh_knownhosts(1) man page to learn about its replacement.
******************************************************************************
But man sss_ssh_knownhosts contains just:
SSS_SSH_KNOWNHOSTS(1) SSSD Manual pages
SSS_SSH_KNOWNHOSTS(1)
NAME
sss_ssh_knownhosts - get OpenSSH known hosts public keys
SYNOPSIS
sss_ssh_knownhosts [options] HOST
DESCRIPTION
sss_ssh_knownhosts acquires SSH public keys for host HOST and outputs
them in OpenSSH known_hosts key format (see the
“SSH_KNOWN_HOSTS FILE FORMAT” section of sshd(8) for more information).
ssh(1) can be configured to use sss_ssh_knownhosts for public key host
authentication using the “KnownHostsCommand”
option:
KnownHostsCommand /usr/bin/sss_ssh_knownhosts %H
Please refer to the ssh_config(5) man page for more details about this
option.
OPTIONS
-d,--domain DOMAIN
Search for host public keys in SSSD domain DOMAIN.
-?,--help
Display help message and exit.
EXIT STATUS
In case of successful execution, even if no key was found, 0 is
returned. 1 is returned in case of error.
SEE ALSO
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5),
sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5),
sssd-sudo(5), sssd-session-recording(5), sss_cache(8),
sss_debuglevel(8), sss_obfuscate(8), sss_seed(8),
sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(1),
sss_ssh_knownhosts(1), sssd-ifp(5), pam_sss(8).
sss_rpcidmapd(5) sssd-systemtap(5)
AUTHORS
The SSSD upstream - https://github.com/SSSD/sssd/
SSSD 07/22/2024
SSS_SSH_KNOWNHOSTS(1)
and no information about a replacement or it being obsolete.
sssd-2.10.0~beta2-3.fc41.x86_64
Reproducible: Always
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2305856
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…