test: Add kerberized sudo to s4u proof of concept #14782
Conversation
croissanne
commented
Oct 20, 2020
•
croissanne
commented
- needs to be released (upstream PR: pam: add pam_sss_gss module for gssapi authentication SSSD/sssd#5367)
- get it on our fedora-33 image (next image rebuild after Feb 12)
croissanne
added
blocked
croissanne
force-pushed
the
krb5-sudo
branch
3 times, most recently
from
5ebbb1e
to
6e26e02
Compare
|
This was released into Fedora 33 yesterday, in sssd 2.4.1. So it's not yet on our fedora-33 image. However, it is on the fedora-testing image in cockpit-project/bots#1668 . @Gundersanne: What is that "/etc/pam.d/teststack"? |
|
Nice, I'll try it out see if it works out of the box. I'll remove |
croissanne
force-pushed
the
krb5-sudo
branch
from
6e26e02
to
69d7ac0
Compare
croissanne
removed
blocked
croissanne
force-pushed
the
krb5-sudo
branch
2 times, most recently
from
a871822
to
64e0382
Compare
test/verify/check-system-s4u-ssh
Outdated
| KRB5CCNAME=/home/user/cache sudo echo hai | ||
| exit 0 | ||
| """) | ||
| client_machine.execute("KRB5_TRACE=\"/dev/stderr\" KRB5CCNAME=\"/etc/cockpit.ccache\" ssh -vvv -K user@sshserver.cockpit.lan bash -c 'KRB5CCNAME=/home/user/cache sudo echo hai'") |
There was a problem hiding this comment.
Could you please run sudo whoami instead, and check that the returned output contains root? That would ensure that it actually worked.
I don't quite understand the difference between the script execution above, and this line? They seem to do similar things?
There was a problem hiding this comment.
I'll do that, the second ssh-ing from the client machine via gssapi auth and then using the cache built above to sudo, putting the 2 things together. But it's indeed just testing the same thing.
croissanne
force-pushed
the
krb5-sudo
branch
from
64e0382
to
670d347
Compare
|
does not work on rhel-8-4 and fedora-33. I think it did before, so there is something more subtle -- perhaps more stdout? I suggest to not just run out = m.execute('...')
self.assertEqual(out, "root") |
croissanne
force-pushed
the
krb5-sudo
branch
2 times, most recently
from
150cf91
to
75a72ad
Compare
There was a problem hiding this comment.
Thank you so much for figuring this out and driving this with the sssd team! Let's get this in to make sure it does not regress, and then we know that the underpinnings are working. We can discuss further simplification of the setup with the sssd team later on.
| systemctl restart sssd | ||
| usermod -G wheel user | ||
| su user | ||
| echo -ne 'foobarfoo\nfoobarfoo\nfoobarfoo\n' | kinit -c /home/user/cache user |
There was a problem hiding this comment.
Why does that need to input the password three times? Forced password change?
| client_machine.execute("KRB5_TRACE=\"/dev/stderr\" KRB5CCNAME=\"/etc/cockpit.ccache\" ssh -vvv -K user@sshserver.cockpit.lan echo hello") | ||
| # configure gssapi authentication for sudo | ||
| sshd_machine.write('/etc/sudoers.d/cockpit-krb5-sudo', """ | ||
| Defaults env_keep += "KRB5CCNAME" |
There was a problem hiding this comment.
This is rather non-obvious. I wonder how we are going to deal with that for the real implementation.. But that is a discussion for another day.
