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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
