1. Forum
  2. Usenet
  3. COMP.SECURITY.SSH

  • What is the difference between SSH_MSG_UNIMPLEMENTED and SSH_MSG_RE

    From Patrik Ek@21:1/5 to All on Fri Feb 21 06:05:56 2020
    Den fredag 21 februari 2020 kl. 14:30:31 UTC+1 skrev Patrik Ek:
    Hi,
    I am currently working with apache sshd library, trying to create an SSH client. To keep the connection up, I want to send an SSH_MSG_GLOBAL_REQUEST with a keep alive message,

    50 00 00 00 15 6b 65 65 70 61 6c 69 76 65 40 6f 70 65 6e 73 73 68 2e 63 6f 6d 01
    translating to
    [email protected],

    where P, is just ascii for 0x50, which is the ID of the SSH_MSG_GLOBAL_REQUEST (https://tools.ietf.org/html/rfc4254)

    So the problem I have here is the reply sent from the server (netopeer-server, which uses libssh under the hood) is SSH_MSG_UNIMPLEMENTED and not SSH_MSG_REQUEST_FAILURE, as I would have expected.

    So what I would need to know is, when is a server expected to send SSH_MSG_UNIMPLEMENTED and when SSH_MSG_GLOBAL_REQUEST?

    BR
    Patrik

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Tatham@21:1/5 to [email protected] on Fri Feb 21 15:53:07 2020
    Patrik Ek <[email protected]> wrote:
    So the problem I have here is the reply sent from the server (netopeer-server, which uses libssh under the hood) is
    SSH_MSG_UNIMPLEMENTED and not SSH_MSG_REQUEST_FAILURE, as I would have expected.

    Section 11.4 in RFC 4253 says that SSH_MSG_UNIMPLEMENTED is for
    "unrecognized messages". That by itself is not very clear, but the
    same paragraph says "Later protocol versions may define other meanings
    for these *message types*" (my emphasis).

    My reading of that is that SSH_MSG_UNIMPLEMENTED is supposed to mean:
    "I don't even recognise the type code of this message, so I have no
    idea at all what kind of reply you might want".

    If an implementation understands the concept of SSH_MSG_GLOBAL_REQUEST
    well enough to know how you extract the request type string, and to
    know that SSH_MSG_REQUEST_FAILURE is one of the possible responses,
    then it should return SSH_MSG_REQUEST_FAILURE if the particular
    request type isn't one it understands (the same as it would for a
    request it does understand but that failed for some other reason).

    If a server were to send me SSH_MSG_UNIMPLEMENTED in response to SSH_MSG_GLOBAL_REQUEST, I think I'd be justified in inferring that the
    server doesn't even know what a global request *is*, and carefully
    avoid sending any further global requests of any type whatsoever!
    --
    import hashlib; print((lambda p,q,g,y,r,s,m: (lambda w:(pow(g,int(hashlib.sha1( m.encode('ascii')).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r and m)(0xb80b5dacabab6145,0xf70027d345023,0x7643bc4018957897,0x11c2e5d9951130c9 ,0xa54d9cbe4e8ab,0x746c50eaa1910, "Simon Tatham <[email protected]>" ))

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Patrik Ek@21:1/5 to All on Fri Feb 21 08:09:47 2020
    Section 11.4 in RFC 4253 says that SSH_MSG_UNIMPLEMENTED is for
    "unrecognized messages". That by itself is not very clear, but the
    same paragraph says "Later protocol versions may define other meanings
    for these *message types*" (my emphasis).

    My reading of that is that SSH_MSG_UNIMPLEMENTED is supposed to mean:
    "I don't even recognise the type code of this message, so I have no
    idea at all what kind of reply you might want".

    If an implementation understands the concept of SSH_MSG_GLOBAL_REQUEST
    well enough to know how you extract the request type string, and to
    know that SSH_MSG_REQUEST_FAILURE is one of the possible responses,
    then it should return SSH_MSG_REQUEST_FAILURE if the particular
    request type isn't one it understands (the same as it would for a
    request it does understand but that failed for some other reason).

    If a server were to send me SSH_MSG_UNIMPLEMENTED in response to SSH_MSG_GLOBAL_REQUEST, I think I'd be justified in inferring that the
    server doesn't even know what a global request *is*, and carefully
    avoid sending any further global requests of any type whatsoever!
    --
    import hashlib; print((lambda p,q,g,y,r,s,m: (lambda w:(pow(g,int(hashlib.sha1(
    m.encode('ascii')).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r
    and m)(0xb80b5dacabab6145,0xf70027d345023,0x7643bc4018957897,0x11c2e5d9951130c9
    ,0xa54d9cbe4e8ab,0x746c50eaa1910, "Simon Tatham <[email protected]>" ))

    Thank you Simon, this is how I have understood it as well. Further RFC 4254, section 4 (https://tools.ietf.org/html/rfc4254#section-4) states,

    "Note that both the client and server MAY send global requests at any time, and
    the receiver MUST respond appropriately.
    ...
    The recipient will respond to this message with SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if 'want reply' is TRUE."

    I interpret this as being mandatory to support the global request type, though not necessarily all global request messages. Or is you of another opinion?

    debug1: Remote protocol version 2.0, remote software version libssh_0.7.5

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)