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

Implements global-requests-ok extension #545

Open
gnodet opened this issue Jul 25, 2024 · 2 comments · May be fixed by #568
Open

Implements global-requests-ok extension #545

gnodet opened this issue Jul 25, 2024 · 2 comments · May be fixed by #568
Labels
feature request A request for a new feature

Comments

@gnodet
Copy link
Contributor

gnodet commented Jul 25, 2024

Description

See https://datatracker.ietf.org/doc/html/draft-ssh-global-requests-ok-00

Motivation

No much useful, but let's advertise the good behaviour.

Alternatives considered

No response

Additional context

No response

@gnodet gnodet added the feature request A request for a new feature label Jul 25, 2024
@tomaswolf
Copy link
Member

Not sure I agree. I think this expired memo is misguided. RFC 4254 requires parties that do not understand a particular global request to reply with SSH_MSG_REQUEST_FAILURE. A peer that fails or disconnects on receiving an unknown global request is just broken. Sending global requests during key exchange is simply illegal (insofar the "at any time" is a bit misleading, but here RFC 4253 overrides). It would be valid for a party to disconnect if it received a global request during an on-going KEX (i.e., both parties have sent their their KEX_INIT, but no NEW_KEYS has been received yet). However, receiving a global request before receiving that party's KEX_INIT is normal and must be handled.

The hostkey rotation global request "[email protected]" is sent only after a session is authenticated.

Finally global requests are a feature of the SSH Connection Protocol, which is not even available before authentication has completed.

I would not complicate our code for this. Did this expired proposal even ever take off? Who implements it?

@gnodet
Copy link
Contributor Author

gnodet commented Jul 25, 2024

Not sure I agree. I think this expired memo is misguided. RFC 4254 requires parties that do not understand a particular global request to reply with SSH_MSG_REQUEST_FAILURE. A peer that fails or disconnects on receiving an unknown global request is just broken. Sending global requests during key exchange is simply illegal (insofar the "at any time" is a bit misleading, but here RFC 4253 overrides). It would be valid for a party to disconnect if it received a global request during an on-going KEX (i.e., both parties have sent their their KEX_INIT, but no NEW_KEYS has been received yet). However, receiving a global request before receiving that party's KEX_INIT is normal and must be handled.

The hostkey rotation global request "[email protected]" is sent only after a session is authenticated.

Finally global requests are a feature of the SSH Connection Protocol, which is not even available before authentication has completed.

I would not complicate our code for this. Did this expired proposal even ever take off? Who implements it?

As indicated in https://www.bitvise.com/ssh-client-version-history-8#821, I think the purpose was to better support such "broken" clients. See also https://www.bitvise.com/ssh-server-version-history-8#841, https://www.bitvise.com/ssh-server-version-history-8#837, https://www.bitvise.com/ssh-server-version-history-8#833, https://www.bitvise.com/ssh-server-version-history-8#822, https://www.bitvise.com/ssh-server-version-history-8#821.

Anyway, while I agree, this looks a bit outdated, it's really just about sending the global-requests-ok as a supported extension, so the impact is very minor to the code.

gnodet added a commit to gnodet/mina-sshd that referenced this issue Jul 26, 2024
@gnodet gnodet linked a pull request Jul 26, 2024 that will close this issue
gnodet added a commit to gnodet/mina-sshd that referenced this issue Jul 26, 2024
gnodet added a commit to gnodet/mina-sshd that referenced this issue Jul 26, 2024
gnodet added a commit to gnodet/mina-sshd that referenced this issue Jul 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request A request for a new feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants