[EKS] [request]: describe request here

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**
We are using below EKS AMI provided by the AWS for the nodes.

Name: amazon-eks-node-1.30-v20250123
ID: ami-090c13b26b923b607

Which are enabled with weak key exchange algorithms as per the SSAT scan done by the security team. Below is the details provided by our security team.

The remote SSH server is configured to allow key exchange algorithms which are considered weak.
This is based on the IETF draft document Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) RFC9142. Section 4 lists guidance on key exchange algorithms that SHOULD NOT and MUST NOT be enabled. This includes:
diffie-hellman-group-exchange-sha1
diffie-hellman-group1-sha1
gss-gex-sha1-*
gss-group1-sha1-*
gss-group14-sha1-*
rsa1024-sha1

Whether it is recommended to configure below strong ciphers in /etc/ssh/sshd_config, because EKS worker nodes use SSH internally during the bootstrap process (for things like joining the cluster, communicating with the API, or pulling updates via SSM). By enabling below ciphers will have impact during the joining the cluster or any other ?
"KexAlgorithms curve25519-sha256,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,
diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256"

**Which service(s) is this request for?**
This could be for EKS

Start by reviewing the EKS AMI details and the proposed /etc/ssh/sshd_config KexAlgorithms list against the worker-node bootstrap and SSH requirements described in the issue. Done means the compatibility impact is established and the issue has a clear recommendation for securing the listed algorithms without disrupting node joining or updates.

Written by the indexing model from the issue text.