On Wed, Jul 3, 2024 at 3:20 PM Manon Goo <manon.goo@xxxxxxxx> wrote:
>
> Dear OpenSSH developers,
>
> Thanks a lot for your work on OpenSSH. We use it a lot and it is very helpful for our daily work. Would it be possible to have a lockdown option as a workaround in case of a remotely exploitable problem in ssh. This may help react to compromised keys/passwords, configuration issues, software bugs or other problems for example when Debian broke ssh .
>
> 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:
This already exists with public-private signed hostkeys. Being
cautious about which publicly signed keys are permitted, from which
private signature authority, should cover this requirement. See:this
sight examples.
https://developer.hashicorp.com/vault/docs/secrets/ssh/signed-ssh-certificates
> - STEP1 When opening the connection the client needs send the protocol information, a Client-Random string and HASH(Client-Random, Shared-Secret). If the HASH(Client-Random, Shared-Secret) does not match then the Server Terminates the connection. This step may be vulnerable to replay attacks , but will offer protection from ssh-scanners and other attackers without privileged access to the network
> - STEP2 The Server answers with the protocol information and a Server-Random string and HASH(Server-Random, Client-Random, Shared-Secret). The Client can now verify that the server knows the Shared-Secret and drop the connection if the hash does not match
> - STEP3 When the client starts the Key Exchange the Client can sent the Server Client-Random2 string and HASH(Client-Random2, Server-Random, Shared-Secret). This second stage should not be vulnerable to replay attacks. The Server can now confidently verify that the client knows the Shared-Secret and drop the connection if the hash does not match.
>
> Perhaps the Shared Secret could have an Index that would need to be included in the handshake, so that different secrets can be used in parallel or be handed out to different Users or for Key Rotarian.
>
> I believe that this could be helpful in situation where Port-knocking is used today and this could give Administrators some workaround when there are problems with ssh and sshd.
>
> How do you like this idea?
>
>
> Kind Regards,
> Manon
>
>
>
>
>
>
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@xxxxxxxxxxx
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
