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: - 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
> This may help react to compromised keys/passwords, configurationissues [...] This use case is best handled at the network layer (i.e.: use a firewall to block connections except from IT staff). As a bonus, it wouldn't require any change to the SSH protocol, nor any new & complex code to be written and maintained long-term. - Joe
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
On Wed, Jul 03, 2024 at 07:18:33PM +0000, 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 . > > [...]> Kind Regards, > ManonSomething that might help you is my sshdo program (github.com/raforg/sshdo). It mitigates private key compromise but only for cases where ssh is used to remotely execute an arbitrary fixed set of commands (e.g. scripted tasks or cronjobs). It doesn't help for interactive ssh use. It gets used as a forced command and it can automatically learn what commands are needed and then only allow those commands. It can also unlearn commands that are no longer in use. It's very easy to use and prevents ssh being used for any command that has not previously been allowed. cheers, raf
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