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

From: "Jeffrey Ladouceur (jladouce)" <[email-masked]>
Date: Fri, 10 Jul 2020 11:48:50 +0000

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)" <[email-masked] on behalf of jladouce=[email-masked]> 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
    [email-masked]
    https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Fri, 10 Jul 2020 20:13:28 +0000

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=[email-masked]> wrote:
> 
> Hello,
>

---

From: "Jeffrey Ladouceur (jladouce)" <[email-masked]>
Date: Fri, 10 Jul 2020 20:21:51 +0000

Hi Kent,

With regards to Juniper, fwiw I found a reference in "JunOS Automation Cookbook" which says:

"NETCONF-over-SSH runs on a separate TCP port to the conventional SSH transport. The default, Internet Assigned numbers Authority (IANA) is 830, but JUNOS OS allows you to select any arbitrary number. When NETCONF-over-SSH is used in this manner, the SSH server makes use of a protocol feature called subsystems. This allows the SSH server to directly connect to another internal component without consideration for details such as pseudo-terminal or user shell."

Base on the last sentence it appears that a pseudo-terminal is not expected when connecting via netconf subsystem.

Appreciated your feedback.

Regards,
Jeff

On 2020-07-10, 4:13 PM, "Kent Watsen" <[email-masked]> wrote:

    Hi Jeff,

    K.