This message was deleted.
# puppet-enterprise
s
This message was deleted.
c
Hmm. Which type of private key are you using? PE uses 1.10.0-DEV because GitHub dropped support in Fall 2021 for using SHA-1 signatures with RSA keys and many other Git hosting services followed.
e
I believe it is a 2048 bit SHA256 RSA key
The fact that I'm seeing this, and no one else is, suggests it is something with either my keys or my ssh server... I'm willing to admit it is something on my end, but I can't figure out what exactly. I think my work arounds are working, so, not a hurry now (though I spent about 3 days trying to fix this over the weekend).
c
Yeah, similar segfaults have occurred in a very small number of cases. So far, we haven't been able to re-produce them on internal test hardware, or GCP VMs built from official OS images, or GitHub action runners, or AWS OS images... Is there any OS hardening applied to these nodes that might affect how they react to how processes access memory?
e
We do harden them, but I wouldn't think it would affect memory access... Good question though, I'd have to check if there is anything in the hardening that could affect memory. While one machine is RHEL and the other Ubuntu, they do get the same basic hardening since it is under puppet management.
c
Is that basic hardening done via a Forge module? If so, that's something we could try applying to a test node to see if it results in segfaults.
e
We do some additional hardening, but most of it is done by the forge module os_hardening (like I say, along with some custom stuff).
os_hardening covers the majority though (>90% probably)
c
👍 I'll give
os_hardening
a try next time I have some slack time.
Oh, which Git Server are you using?
e
It is a local machine, running stock RHEL 7 with stock openssh 7.4p1-22.el7_9.x86_64. We do have the account set to use /usr/bin/git-shell as the shell. Using public key auth obviously with the type of key mentioned previously.
Both the puppet server and the git server both have the os_hardening module applied.