What Actually Happens When You SSH Into a Router

brett@network-notes.com (Brett Lykins) — Thu, 23 Apr 2026 11:00:00 +0000

You type ssh router1, hit enter, and a prompt appears. Simple.

Between those two events, your client and the device exchange dozens of packets across four protocol layers, negotiate cryptographic algorithms, perform a key exchange, authenticate you, open a channel, and (if you’re using a tool like Netmiko) request a pseudo-terminal, detect the prompt, disable pagination, and set the terminal width. All before a single show command runs.

Most network engineers use SSH every day without thinking about any of this. That’s fine for interactive use. But if you’re building automation that opens hundreds or thousands of SSH sessions, every one of those steps costs at least one network round trip (sometimes more), and round trip times are usually the single biggest factor in how fast your automation runs.

SSH Is Four Protocols, Not One

SSH isn’t a single protocol. It’s a stack of four, defined across separate RFCs:

Layer	RFC	What it does
Architecture	RFC 4251	Defines the overall design, terminology, and trust model
Transport	RFC 4253	Key exchange, encryption, integrity, server authentication
Authentication	RFC 4252	User authentication (password, publickey, keyboard-interactive)
Connection	RFC 4254	Channels, multiplexing, port forwarding, sessions

Each layer runs on top of the previous one. The transport layer gives you an encrypted pipe. The authentication layer proves who you are. The connection layer multiplexes that pipe into channels, and channels are where the actual work happens.

The application (your shell session, your show version command, your NETCONF RPC) rides on top of a channel.

TCP

SSH runs over TCP; so before any SSH packets flow, you need a TCP connection:

Client → Server: SYN
Server → Client: SYN-ACK
Client → Server: ACK

Cost: 1 round trip. The ACK can piggyback on the first SSH data, but the connection isn’t usable until the handshake completes.

This is the same cost every TCP-based protocol pays. Nothing SSH-specific yet.

SSH Transport

Protocol Version Exchange

Immediately after TCP connects, both sides send an identification string:

1
2


SSH-2.0-OpenSSH_9.6
SSH-2.0-Cisco-1.25

Both sides send simultaneously, so this can overlap with the TCP ACK. In practice, the client usually sends first and waits for the server’s response.

Cost: 1 round trip for the version exchange. Implementations vary on whether KEXINIT is pipelined with the version string or sent after receiving the server’s version.

Algorithm Negotiation (KEXINIT)

Both sides send SSH_MSG_KEXINIT, a packet listing every algorithm they support, in preference order:

Key exchange methods (e.g., curve25519-sha256, diffie-hellman-group14-sha256)
Host key algorithms (e.g., ssh-ed25519, rsa-sha2-512)
Encryption algorithms (e.g., aes256-gcm@openssh.com, chacha20-poly1305@openssh.com)
MAC algorithms (e.g., hmac-sha2-256-etm@openssh.com)
Compression algorithms (usually none)

RFC 4253 says “key exchange will begin immediately after sending [the version] identifier,” meaning each side can fire off its KEXINIT right after its version string without waiting. If both sides do this, the KEXINIT packets arrive during the same round trip as the version exchange, and the cost is zero additional round trips. If the client waits for the server’s version string before sending KEXINIT (which some implementations do), it costs a separate round trip.

Cost: 0-1 round trips depending on whether the implementation pipelines KEXINIT with the version string.

Key Exchange

The exact packet sequence depends on the algorithm:

Modern (curve25519-sha256, ecdh-sha2-nistp256): 1 round trip.

Client → Server: SSH_MSG_KEX_ECDH_INIT (client’s ephemeral public key)
Server → Client: SSH_MSG_KEX_ECDH_REPLY (server’s ephemeral public key + host key + signature)

Both sides now have a shared secret. The server’s signature proves it holds the private key matching the host key the client expects.

Legacy (diffie-hellman-group-exchange-sha256): 2 round trips.

Client → Server: SSH_MSG_KEX_DH_GEX_REQUEST (preferred group size)
Server → Client: SSH_MSG_KEX_DH_GEX_GROUP (prime and generator)
Client → Server: SSH_MSG_KEX_DH_GEX_INIT (client’s public value)
Server → Client: SSH_MSG_KEX_DH_GEX_REPLY (server’s public value + signature)

The extra round trip exists because the client asks the server to choose a DH group, rather than using a fixed one. Older network devices that don’t support curve25519 or ECDH may force this path.

Cost: 1-2 round trips depending on the algorithm.

After key exchange completes, both sides send SSH_MSG_NEWKEYS simultaneously to activate the new keys (no additional round trip). The client then requests the ssh-userauth service via SSH_MSG_SERVICE_REQUEST / SSH_MSG_SERVICE_ACCEPT, costing 1 round trip. Some implementations (like OpenSSH) pipeline this with NEWKEYS, but many wait.

Transport layer total: 3-5 round trips (TCP + version exchange + KEXINIT + kex + service request).

SSH Authentication

The client now needs to authenticate. This is where things get variable, because the server controls which methods it accepts and in what order.

The Auth Dance

The client sends an authentication request. If it fails or the server wants to advertise available methods, the server responds with SSH_MSG_USERAUTH_FAILURE plus a list of methods that can continue.

A typical sequence for password auth:

Client → Server: SSH_MSG_USERAUTH_REQUEST (method: “none”) to discover available methods
Server → Client: SSH_MSG_USERAUTH_FAILURE (methods: “publickey,password”)
Client → Server: SSH_MSG_USERAUTH_REQUEST (method: “password”, password: “…”)
Server → Client: SSH_MSG_USERAUTH_SUCCESS

Cost: 2 round trips for password auth with a method probe.

For public key auth, it’s often 2-3 round trips:

Probe (1 RT)
Public key query: “will you accept this key?” (1 RT)
Actual signature-based auth (1 RT)

Some servers skip the probe if the client guesses correctly on the first try. Some clients try multiple key types before finding one the server accepts. Each failed attempt is another round trip.

Authentication total: 1-3 round trips depending on method and implementation.

SSH Connection

With an authenticated, encrypted connection established, the client can now open channels. For automation, this layer matters most, because there are three fundamentally different ways to interact with a device.

Channel Basics

Every channel follows the same lifecycle:

Client → Server: SSH_MSG_CHANNEL_OPEN (channel type, initial window size)
Server → Client: SSH_MSG_CHANNEL_OPEN_CONFIRMATION (window size, max packet size)
… data flows …
Either side: SSH_MSG_CHANNEL_CLOSE

Cost: 1 round trip to open a channel.

SSH channels have their own flow control, independent of TCP, with each side advertising a receive window size.

Channel Type 1: Shell (PTY)

This is what happens when you type ssh router1 and get an interactive prompt. It’s also what Netmiko, Ansible network_cli, and Scrapli use for automation.

After opening a session channel:

Client → Server: SSH_MSG_CHANNEL_REQUEST (type: “pty-req”, terminal type, dimensions)
Server → Client: SSH_MSG_CHANNEL_SUCCESS
Client → Server: SSH_MSG_CHANNEL_REQUEST (type: “shell”)
Server → Client: SSH_MSG_CHANNEL_SUCCESS

Cost: 2 round trips (PTY request + shell request).

Now you have a byte stream. The server sends a prompt (router1#). You send characters. The server echoes them back. You send a newline. The server processes the command and sends the output, followed by another prompt.

The catch: there is no framing. The server doesn’t tell you “the command output is 847 bytes long” or “I’m done sending.” It just sends bytes. Your automation tool has to figure out when the output is complete by pattern-matching the prompt, which is why Netmiko spends so much effort on prompt detection, and why it sends terminal length 0 (to disable pagination) and terminal width 511 (to prevent line wrapping) before running any real commands.

Each of those setup commands is another write-read-prompt cycle on the channel.

Channel Type 2: Exec

This is what happens when you run ssh router1 "show version" from the command line. It’s also what Go’s x/crypto/ssh, Paramiko’s exec_command(), and some other programmatic SSH libraries in various languages use.

After opening a session channel:

Client → Server: SSH_MSG_CHANNEL_REQUEST (type: “exec”, command: “show version”)
Server → Client: SSH_MSG_CHANNEL_SUCCESS
Server → Client: SSH_MSG_CHANNEL_DATA (command output)
Server → Client: SSH_MSG_CHANNEL_REQUEST (type: “exit-status”, code: 0)
Server → Client: SSH_MSG_CHANNEL_CLOSE

Cost: 1 round trip for the exec request, then the output streams back.

Exec mode is cleaner than shell mode: one command, one channel, structured exit. No prompt detection, no pagination, no terminal width issues. But there are some catches.

First, each command needs its own channel. If you want to run 5 commands, you open 5 channels, meaning 5 channel-open round trips plus 5 exec-request round trips.

Second, many network devices don’t support exec mode properly (or at all), which is why most automation tools default to shell/PTY mode.

Channel Type 3: Subsystem (NETCONF)

NETCONF (RFC 6241) runs over SSH as a subsystem, a named service that the server knows how to handle.

After opening a session channel:

Client → Server: SSH_MSG_CHANNEL_REQUEST (type: “subsystem”, name: “netconf”)
Server → Client: SSH_MSG_CHANNEL_SUCCESS

Cost: 1 round trip.

Then NETCONF has its own handshake on top of the SSH channel:

Both sides simultaneously: <hello> messages listing capabilities
Client → Server: <rpc> request
Server → Client: <rpc-reply> response

The <hello> exchange is 1 round trip. Each RPC is 1 round trip. Messages are delimited by ]]>]]> (the legacy base:1.0 framing) or chunked framing with \n#length\n headers (base:1.1), both defined in RFC 6242.

NETCONF gives you structured XML data and transactional semantics (<edit-config>, <commit>, <validate>), which beats screen-scraping CLI output by a wide margin. But it pays the full SSH transport cost to get there, plus its own capability exchange overhead.

The Round-Trip Tally

Here’s what it all adds up to, from TCP SYN to first byte of command output:

Step	Round trips	Notes
TCP handshake	1	Same for any TCP protocol
SSH version exchange + KEXINIT	1-2	Pipelined: 1 RT; sequential: 2 RT
Key exchange (modern)	1	curve25519/ECDH
Key exchange (legacy)	2	DH group exchange
NEWKEYS + service request	1	Often pipelined
Authentication	1-3	Password: 2, pubkey: 2-3
Channel open	1
PTY + shell request	2	Shell/PTY mode only
Exec request	1	Exec mode only
Subsystem request	1	NETCONF only
NETCONF hello exchange	1	NETCONF only

SSH CLI (exec mode): 6-10 round trips before the first command output.

SSH CLI (PTY/shell mode): 7-11 round trips before the first command output, plus 2-3 more for session prep (terminal length 0, terminal width 511).

NETCONF over SSH: 7-11 round trips before the first RPC response, plus 1 for the NETCONF hello exchange.

For comparison:

HTTPS (TLS 1.3): 3 round trips total: TCP (1) + TLS 1.3 handshake (1) + HTTP request (1). With connection reuse: 1 round trip per request.

NETCONF vs RESTCONF: Same Data, Different Pipe

So far this post has been about what happens inside an SSH connection. But SSH isn’t the only way to talk to a network device programmatically. NETCONF and RESTCONF both operate on YANG data models, and they can configure the same things on the same devices. The difference is the transport.

	NETCONF	RESTCONF
Transport	SSH (subsystem channel)	HTTPS
Data format	XML	JSON or XML
Connection setup	7-11 RT (SSH)	3 RT (TLS 1.3)
Per-operation cost	1 RT (RPC request/reply)	1 RT (HTTP request/response)
Connection reuse	SSH connection persists	HTTP keep-alive (default)
Framing	`]]>]]>` or chunked	HTTP Content-Length
Capabilities	Explicit hello exchange	YANG library (RFC 7895)
Transactions	`<commit>`, `<validate>`, `<discard-changes>`	No candidate datastore; edits apply immediately to running config

NETCONF’s advantage is its transactional model: candidate configs, commit/rollback, validation. RESTCONF trades some of that for a simpler transport with lower connection overhead and native compatibility with standard HTTP client libraries and load balancers.

For automation at scale, the transport cost matters. If you’re making hundreds of NETCONF calls across a WAN, you’re paying the SSH handshake tax on every new connection. RESTCONF over HTTPS with connection reuse eliminates that entirely.

I’m planning to benchmark both SSH CLI vs HTTPS CLI and NETCONF vs RESTCONF with real measurements: same device, same operations, same latency profiles. Theory is useful, but packet captures don’t lie.

Why This Matters for Automation

If you’re managing 1,000 devices across a WAN with 75ms latency, the math gets ugly. Each SSH connection pays 450-750ms in handshake overhead before it does anything useful. Parallelism helps with wall clock time, but it doesn’t reduce the per-device tax, and every one of those connections is burning round trips, file descriptors, and CPU on your automation host.

I’ll be measuring this gap with real numbers in an upcoming series on CLI over HTTPS. Early testing shows that at 30ms RTT, HTTPS batch mode is roughly 5x faster than SSH for the same CLI commands, because it pays 3 round trips instead of 7-11.

My take: SSH is a good protocol for what it was built for: giving one person a secure shell on one machine. Every layer in the stack exists for a reason. But those layers add up to a lot of round trips, and that cost compounds when you’re hitting a thousand devices over a WAN. The protocol wasn’t designed for “blast 5 commands at 1,000 boxes as fast as possible.” Once you see the round-trip tax on the wire, the performance gap between SSH and HTTPS stops being surprising.

Protocols on network-notes

What Actually Happens When You SSH Into a Router

SSH Is Four Protocols, Not One

TCP

SSH Transport

Protocol Version Exchange

Algorithm Negotiation (KEXINIT)

Key Exchange

SSH Authentication

The Auth Dance

SSH Connection

Channel Basics

Channel Type 1: Shell (PTY)

Channel Type 2: Exec

Channel Type 3: Subsystem (NETCONF)

The Round-Trip Tally

NETCONF vs RESTCONF: Same Data, Different Pipe

Why This Matters for Automation