Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remoteshell postscript creates incorrect sshd_config for openssh 8.9p1 #7493

Open
sjjf opened this issue Mar 15, 2025 · 0 comments
Open

remoteshell postscript creates incorrect sshd_config for openssh 8.9p1 #7493

sjjf opened this issue Mar 15, 2025 · 0 comments
Milestone

Comments

@sjjf
Copy link
Contributor

sjjf commented Mar 15, 2025

The xCAT/postscripts/remoteshell script has the following code:

         sed -i '/MaxStartups /'d /etc/ssh/sshd_config
         echo "MaxStartups 1024" >>/etc/ssh/sshd_config

(lines 64-65)

This causes issues with openssh version 8.9p1 (as ships in Ubuntu 22.04), and potentially some newer versions - see https://lists.mindrot.org/pipermail/openssh-bugs/2022-March/023864.html for more details. The issue manifests either as connection attempts spinning indefinitely, or simply failing, and messages like this in the logs:

Mar 14 12:12:32 ccn10201 sshd[1331]: error: ppoll: Invalid argument

This issue makes it impossible to log into a newly built node with an affected version of openssh.

The fix is simply dropping the value to 1023 (or anything less than 1024).

It might also be worth considering whether this setting is actually needed. MaxStartups sets a limit on the number of unauthenticated connections that can be made - i.e. connections that are in the process of authenticating. It's primarily a DoS protection, in a (notionally) friendly environment like an xCAT managed cluster it probably doesn't have much use outside pathological scenarios (e.g. a very busy node that's not able to process new connections fast enough).

It's worth noting that current openssh defaults to MaxSessions 10 and xCAT makes no change to this setting - i.e. we allow no more than 10 concurrent shell, login or subsystem sesssions. Allowing 10 times as many connections to be waiting on authentication as can actually do anything seems a bit pointless.

I'm happy to submit a pull request either adjusting the value or dropping it entirely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants