How does a NETCONF client open a session over SSH, and why does NETCONF run as an SSH subsystem rather than through a shell?
answer
- layers before any XML
- a named subsystem, not a channel type
- an IANA-assigned port, not 22
- no prompts or banners to parse
basics
~20 sA NETCONF client connects to TCP port 830, authenticates over SSH, opens an SSH session channel and requests the subsystem named "netconf". The subsystem hands the channel straight to the NETCONF server, so no shell prompt or login banner corrupts the XML stream.
solid answer
~40 sRFC 6242 layers NETCONF on SSH in a fixed order: the SSH transport (key exchange, server authentication, encryption), then the `ssh-userauth` service, then `ssh-connection`, then a channel of type `"session"`, and finally a subsystem request for `"netconf"`. Servers **must default** to offering that subsystem only on TCP **830**, the IANA-assigned port, so firewalls can identify and filter NETCONF; other ports are a configurable option. Running as a subsystem means the channel carries nothing but NETCONF messages: no shell start-up text, no prompt to recognise, no screen-scraping. The authenticated SSH username becomes the NETCONF username unchanged. Once the subsystem starts, both sides send `<hello>`; the session later ends with `<close-session>`, after which the server replies and closes the channel. RFC 6241 makes this SSH mapping mandatory to implement.
go deeper
Recall the order: SSH connection and login, a session channel, then the netconf subsystem on port 830, then the hello exchange. Say why a subsystem beats screen-scraping a shell.
Separate the layers precisely: the channel type is session and netconf is the subsystem name; the SSH username becomes the NETCONF username unchanged; close-session makes the server reply and close the channel.
Show operational judgement: port 830 as the filterable default, the risk of enabling the subsystem on other ports without firewall changes, and how a dropped connection releases the session's locks.
Frame the transport choice: SSH is the mandatory-to-implement mapping every peer shares, while TLS and call home suit certificate-managed fleets and devices that cannot accept inbound connections.
## The short version **NETCONF** (RFC 6241, which obsoletes RFC 4741) is an XML-based protocol for reading and changing a network device's configuration. It defines messages, not a transport: it needs a connection that is reliable, ordered, authenticated, encrypted and long-lived, and it leaves that job to a **transport mapping**. RFC 6241 Section 2.3 says every implementation **MUST support** the SSH mapping, which is **RFC 6242** (it obsoletes RFC 4742). Other mappings exist, such as NETCONF over TLS (RFC 7589), but SSH is the one every client and server can rely on. ## The layers, in the order they come up RFC 6242 Section 3 describes the start of a session as a stack built one layer at a time: 1. The client opens a TCP connection to the server, by default to **TCP port 830**. 2. The **SSH transport protocol** runs: the two sides exchange keys for encryption and integrity, and the client verifies the server's host key. 3. The client invokes the **`ssh-userauth`** service and the user authenticates. 4. The client invokes **`ssh-connection`**, the SSH connection protocol. 5. The client opens a channel of type **`"session"`**. 6. On that channel the client asks for the SSH **subsystem** named **`"netconf"`**. 7. The NETCONF layer starts: each side sends a `<hello>` listing its capabilities, and the server's hello carries the session ID. Steps 2 and 3 belong to SSH itself, and how key exchange, host keys and user authentication work is SSH's subject rather than NETCONF's. What NETCONF adds starts at step 5. A frequent slip is to call `netconf` an SSH *channel type*: the channel type is the ordinary `"session"`, and `netconf` is the name of the **subsystem** requested on it. ## Why a subsystem and not a shell An SSH **subsystem** is a named service that the server attaches directly to the channel. Subsystems are a feature of **SSH version 2**; RFC 6242 notes they do not exist in SSHv1. The alternative, opening an interactive shell and typing into it, is what screen-scraping automation does, and RFC 6242 names exactly what it avoids: - no need for the client to **recognise shell prompts**; - no need to **skip extraneous output**, such as a system message printed at shell start-up; - the byte stream on the channel is **only NETCONF messages**, so the framing that delimits them (end-of-message `]]>]]>` or chunked framing) is never disturbed by text the device prints for humans. The same idea serves other protocols that ride SSH: a file-transfer subsystem gets the same clean channel. The subsystem name is registered with IANA, so client and server agree on what `"netconf"` means. ## Port 830 and what the RFC actually requires | Point | What RFC 6242 says | |---|---| | Default port | NETCONF servers **MUST** default to offering the `netconf` subsystem only on sessions established to TCP **830** | | Other ports | Servers **SHOULD** be configurable to offer it on other ports | | Why a dedicated port | So NETCONF traffic can be **identified and filtered** by firewalls and other network devices | | The cost | A dedicated port also makes NETCONF easier for attackers to identify | | The trap | Enabling another port without matching firewall changes may expose NETCONF beyond an administrative boundary | So "NETCONF runs on port 22" is wrong as a statement of the protocol: port 22 is ordinary SSH, and a server that offers the subsystem there has been configured away from the RFC's default. ## The NETCONF username NETCONF has no login message of its own. RFC 6241 requires the transport to deliver an **authenticated identity**, the **NETCONF username**, whose permissions the server then enforces for the life of the session. Over SSH, RFC 6242 says the username the SSH implementation authenticated is passed to NETCONF **without modification**, and if that name cannot be represented in XML, the SSH session **MUST be dropped**. Any mapping the SSH server applies to system accounts is outside the RFC's scope. ## How the session ends The orderly exit is the `<close-session>` operation. The server processes messages **in the order received**; when it reaches `<close-session>` it **SHALL respond and close the SSH channel**, and it **MUST NOT** process anything received after it. RFC 6241 Section 7.8 adds that the server releases the session's locks and resources. If the connection simply drops instead, RFC 6241 Section 2.1 still requires that resources held for that connection be released automatically, so a crashed script does not hold a lock forever. ## Misreadings to avoid - **"NETCONF does its own authentication."** It relies on the transport; the SSH-authenticated user *is* the NETCONF user. - **"Any SSH version will do."** The subsystem mechanism is SSHv2 only. - **"NETCONF drives the CLI over SSH."** It exchanges structured XML on a dedicated subsystem; no CLI text is involved. - **"830 is mandatory."** It is the required *default*; other ports are permitted by configuration, with the firewall caveat above.
- May a NETCONF server offer the netconf SSH subsystem on a port other than 830?Yes, by configuration. RFC 6242 says servers MUST default to offering the subsystem only on TCP 830 and SHOULD be configurable for other ports. Its security section warns that opening another port without matching firewall or device changes can let nodes outside an administrative boundary reach NETCONF, because filters written for 830 no longer match.
- What happens if the SSH-authenticated username cannot be represented in XML?RFC 6242 passes the SSH username to NETCONF unchanged as the NETCONF username, and RFC 6241 requires that name to be a string of XML characters. If it is not representable in XML, the SSH session MUST be dropped; the NETCONF layer never starts for that user.
- What does the server do when it processes a <close-session> on a NETCONF over SSH session?It handles messages in arrival order, so everything sent before <close-session> is processed first. Then it replies, closes the SSH channel, releases the session's locks and resources, and processes nothing received after the <close-session>.
saying these in an interview costs you the question
- NETCONF opens its own SSH channel type called netconf.
- NETCONF over SSH listens on port 22 by default, like any SSH service.
- NETCONF automates the device by typing commands into an interactive SSH shell.
- NETCONF performs its own user login after the SSH session is up.
- Any SSH version can carry NETCONF as long as it encrypts.