Manon, On Thu, 4 Jul 2024 at 05:00, Manon Goo <manon.goo at dg-i.net> wrote:> My Idea would be to have a shared secret option that the client and server would have to proof to know when initiating the Handshake. The Server or client could terminate the connection immediately when the peer does not know the secret. So in case of a security Problem the administrator could set an option for ssh and sshd like LockDownSharedSecret to a random password and share it with other Trustworthy Administrators, who are involved in fixing the problem. My ideas how to use this shared secret:How is this different to configuring /etc/securetty and tunnelling Telnet over SSH Port Forwarding which I don't recommend BTW? -- Regards, Christian Heinrich http://cmlh.id.au/contact
Dear Christian,>How is this different to configuring /etc/securetty and tunnelling >Telnet over SSH Port Forwarding which I don't recommend BTW?In case your SSH is remotely attackable for instance - because your LDAP is configured wrongly, - your run into some problem like CVE-2008-0166 - some users private keys are lost And you want to lock down the sshd and investigate and fix the problem, then your solution may not be helpful because SSH is still exposed and attackable. The solution I do propose is an alterative to Port-Knocking or packet filtering because it aims to un-expose the vulnerability of ssh and give the Administrators some time to fix the problems. Kind Regards Manon
> How is this different to configuring /etc/securetty and tunnelling > Telnet over SSH Port Forwarding which I don't recommend BTW?P.S: The idea is about being able to Lockout a potential attacker very early in the protocol (before the key handshake happens) as a workaround until vulnerabilities can be properly fixed and not about Authenticating or Authorizing users for their regular login process. Manon