-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
x/crypto/ssh: fix documention for ssh.NewServerConn to avoid potential DoS attack #43521
Labels
Documentation
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
ncw
added a commit
to rclone/rclone
that referenced
this issue
Jan 5, 2021
Before this change, if one connection was authenticating this would block any others from authenticating. This was due to ssh.NewServerConn not being called in a go routine after the Accept call. This is fixed by running the ssh authentication in a go routine. Thanks to @FiloSottile for advice on how to fix this. See: golang/go#43521
toothrot
added
the
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
label
Jan 5, 2021
ncw
added a commit
to rclone/rclone
that referenced
this issue
Jan 6, 2021
#4882 Before this change, if one connection was authenticating this would block any others from authenticating. This was due to ssh.NewServerConn not being called in a go routine after the Accept call. This is fixed by running the ssh authentication in a go routine. Thanks to @FiloSottile for advice on how to fix this. See: golang/go#43521
ncw
added a commit
to rclone/rclone
that referenced
this issue
Jan 13, 2021
#4882 Before this change, if one connection was authenticating this would block any others from authenticating. This was due to ssh.NewServerConn not being called in a go routine after the Accept call. This is fixed by running the ssh authentication in a go routine. Thanks to @FiloSottile for advice on how to fix this. See: golang/go#43521
negative0
pushed a commit
to negative0/rclone
that referenced
this issue
Aug 13, 2021
rclone#4882 Before this change, if one connection was authenticating this would block any others from authenticating. This was due to ssh.NewServerConn not being called in a go routine after the Accept call. This is fixed by running the ssh authentication in a go routine. Thanks to @FiloSottile for advice on how to fix this. See: golang/go#43521
This was referenced Mar 19, 2023
Change https://go.dev/cl/570975 mentions this issue: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Documentation
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I followed the example here for building an ssh server: https://gist.github.com/jpillora/b480fde82bff51a06238
This contains the code
The problem with this code is that calling
ssh.NewServerConn
can take an arbitrary length of time as it might have to ask the user for a password. In fact calling it like this is setting up a potential DoS attack - one user can take as long as desired to do the authentication, blocking any other users from connecting.The documentation for
ssh.NewServerConn
should be changed to say that it must be called in a new go routine and should not be called in in the same go routine as theListen
loop.It might be a good idea if the example for ssh.NewServerConn was changed to show a loop around the
Listen
call with thessh.NewServerConn
being called in a go routine.This was originally discovered in rclone/rclone#4882 - thanks to @FiloSottile for working out the cause of the problem and suggesting making this issue.
The text was updated successfully, but these errors were encountered: