On 04.07.24 01:41, Manon Goo wrote:> - some users private keys are lost
Then you go and remove the corresponding pubkeys from wherever they're
configured.
Seriously, even if you do not scan which pubkey is configured where
*now* (as is part of our usual monitoring), it'll be your "number
<3"
task *then* to go hunt it down.
> And you want to lock down the sshd and investigate and fix the problem
Then block SSH wherever you can *except* for a jump host that you set up
with a known good version and grant your fellow sysadmins access to.
"Lock down sshd 'cause it's dubitable" and "trust a
rarely-used
mechanism inside it to do so" don't mix - after all, the backdoor of
CVE-2024-3094 allowed the attacker to bypass *some* of the normal crypto
routines, too.
(And since you mention "port knocking", I'd like to repeat how
fond I am
of upgrading that original concept to a single-packet crypto-armored
implementation like fwknop.)
Kind regards,
--
Jochen Bern
Systemingenieur
Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20240704/c7df627e/attachment.p7s>