mina-sshd icon indicating copy to clipboard operation
mina-sshd copied to clipboard

Implements global-requests-ok extension

Open gnodet opened this issue 1 year ago • 2 comments

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 avatar Jul 25 '24 10:07 gnodet

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?

tomaswolf avatar Jul 25 '24 11:07 tomaswolf

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 avatar Jul 25 '24 12:07 gnodet