Request for a Lockdown option

[Nico Kadel-Garcia]

On Wed, Jul 3, 2024 at 3:20 PM Manon Goo <manon.goo at dg-i.net> 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 at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev