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

Hi Jeff,

I’m unfamiliar with how the negative case is handled on Juniper devices (I used to work there).

Perhaps you could write a portable script to test the various ways a client might try to start a NETCONF session and ask folks to run it and report findings here?   [Be sure the script is a small as possible to aid folk’s ability to audit it first.]

Otherwise, I don’t know if there is an official standards-based answer to this.

K.

> On Jul 10, 2020, at 7:48 AM, Jeffrey Ladouceur (jladouce) <jladouce=40cisco.com@dmarc.ietf.org> wrote:
> 
> 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)" <netconf-bounces@ietf.org on behalf of jladouce=40cisco.com@dmarc.ietf.org> 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
>    netconf@ietf.org
>    https://www.ietf.org/mailman/listinfo/netconf
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf