Re: [netconf] Question about RFC 6242 : netconf over ssh

["Jeffrey Ladouceur (jladouce)" <[e-mail]>]

Hello,

Maybe I'll try and re-phrase.

Our netconf subsystem expects to be connected directly to the forked sshd process via pipes.
It does not expect to be connected to a pseudo terminal device.

If a client requests that a pty device be allocate just prior to invoking the netconf subsystem, the default linux N_TTY line disciple device will interfere with the netconf-over-ssh protocol.

I've seen various netconf implementations not be affected by this use-case, mainly because they have customized the ssh server to either:
- treat the pty-req as a nop (see https://github.com/CESNET/libnetconf2/blob/aaaada2ae38bed7601d12965b1c9fd826f855bab/src/session_server_ssh.c#L1074 )
- undo the pty allocation and revert to using pipes when the netconf subsystem is invoked.

However other netconf server simply treat this as a "garbage-in/garbage-out" scenario. If the client has chosen to allocate a pseudo-terminal then can we treat this is a misconfiguration and the netconf server is under no obligation to fix a misbehaving client.

Our netconf subsystem could easily check if SSH_TTY is set and exit as this would protect the client from receiving incorrect data.

Or we could leave it as.

I was wondering if the community had any input on such a use-case.

Regards,
Jeff



On 2020-05-07, 4:59 PM, "netconf on behalf of Jeffrey Ladouceur (jladouce)" <[e-mail] on behalf of jladouce=[e-mail]> wrote:

    Hello,

    I would like some input on a the following use-case and possible acceptable outcomes. 

    Summary:

    RFC 6242 doesn't explicitly indicate any lower level messaging in RFC 4254 which could "break" the netconf messaging between client and server.
    Specifically, the client can send a https://tools.ietf.org/html/rfc4254#section-6. "pty-req" just prior to invoking the "netconf" ssh subsystem.
    Having a pseudo-terminal device in between the client-server could result in the breakage of the messaging being client/server. 

    RFC 6242 states:
    https://tools.ietf.org/html/rfc6242#section-3 (Starting NECONF over SSH)

    1. Once the user has been successfully authenticated, the SSH client will invoke the "ssh-connection" service, also known as the SSH connection protocol.
    2. After the ssh-connection service is established, the SSH client will open a channel of type "session", which will result in an SSH session.
    3. Once the SSH session has been established, the NETCONF client will invoke NETCONF as an SSH subsystem called "netconf".
    4. Running NETCONF as an SSH subsystem avoids the need for the script to recognize shell prompts or skip over extraneous information, such as a system message that is sent at shell start-up.

    If I were to translate these steps into the corresponding RFC 4254 messages.

    Step (2) translates to:
    https://tools.ietf.org/html/rfc4254#section-6.1 (Opening a Session) , upon which a session has been established

    Step (3), this translates to https://tools.ietf.org/html/rfc4254#section-6.5 (Starting a Shell or a Command), but specifically the "subsystem" variant.
    With a string of “subsystem” and “subsystem name” set to netconf.

    Question:
    1- Does  RFC 6242 imply that it expects direct client/server connection without any interference from a pty device ? The text in item (4) appears to me to imply this.

    From what I can tell, the usage of this pty pattern is when a client wants netconf over tty.

    Thank you for any feedback.

    Regards,
    Jeff

    _______________________________________________
    netconf mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/netconf