Console

What it does: connects over SSH (encrypted), Telnet (plaintext), or a local serial/COM port straight into a device's console — the pre-network way in for factory-fresh gear that has no IP configured yet. Same command box, same history, same safety gating every way. SSH supports password auth (the usual choice for initial setup, since a fresh device has no key trust established) or key-based auth for gear you've already provisioned with one.

Saved hosts: the side panel (the Saved hosts button shows or hides it; formerly the separate Quick console tool) holds your saved SSH / Telnet connections for one-click login, like the host list in any SSH client, so you never retype an address. Build one straight from a discovered NETWORK device: the picker lists switches, routers, firewalls and access points found by LAN discovery (endpoints like PCs, servers and TVs are left out on purpose). Pick a device to fill its address, add a username, then either link a Vault credential (preferred — one source of truth) or store a local password encrypted on this machine (DPAPI on Windows, AES-GCM on Linux), tied to your account and machine and never written in plain text. Each saved host opens its own protocol — a Telnet host opens Telnet (port 23 by default), an SSH host SSH (22). Connect opens the session here; if the credential is in a locked Vault you're taken to unlock it and the session opens the moment it's unlocked. Multi-host run and the SPOG Saved hosts widget read the same list. Two databases, kept separate: discovered devices live in Inventory/Topology; Saved hosts is the curated subset you've added credentials to. Treat saved credentials like any password store.

Telnet: WARNING — Telnet is UNENCRYPTED: your credentials and every keystroke cross the network in clear text. Use it only when SSH isn't available, on a trusted or console/management network, and switch the device to SSH as soon as you can. It's for gear whose crypto/SSH isn't enabled yet, or that has no key or license for it — a common reality on brand-new or lab switches. There are no username/key fields: Telnet login is in-band, so you connect to just a host and port (23), then answer the device's own Username:/Password: prompts in the command box (which masks what you type on a password prompt).

Safe to run: with care — these are real commands on real gear. A wrong command can disrupt a device, and on a serial console during greenfield setup there's often no prior working config to fall back to.

Safety gating (three tiers): Read-only ON (the default) blocks config changes and destructive commands; OFF runs changes, and a destructive command only after a loud warning. Read commands (show/ping/trace, and getting to enable) always run. Config CHANGES and device-DESTRUCTIVE commands (reload, reboot, write erase, erase/format, factory-reset) are gated by the Read-only toggle:

• Read-only mode ON (default) — holds BOTH: a change or destructive command is blocked with a note; nothing is sent.
• Read-only mode OFF — config changes run normally; a destructive command runs only after a loud on-screen warning, and the device's own "Proceed? [confirm]" is the final gate. Nothing destructive fires silently.

Your choice sticks: the toggle ships ON (safe by default), but whatever you last set is remembered across sessions — an advanced engineer who works with it OFF won't have to re-uncheck it every launch.

Copy text out: click-and-drag across the terminal to select, then Ctrl+C to copy the selection to the clipboard (right-click still pastes). Handy for lifting an interface name, MAC, or a line you typed in read-only mode over into config mode. If nothing is selected, Ctrl+C sends the normal interrupt to the device.

Config snippets: "Send all lines" pushes a pasted or imported block line by line — it types each line, watches the device's reply, and STOPS at the first error (naming the line and why), so a bad line can't cascade. It runs EXACTLY what you paste — it never edits, reorders, or skips your commands; it only guards, warns, and reports. Prerequisites: be connected, at an enable/config prompt (type "en", then "conf t" — do that yourself), and with Read-only mode unchecked.

Generate rollback: after a push applies, "↩ Generate rollback" builds a DRAFT that undoes it — the inverse commands (shutdown⇄no shutdown, and "no …" to remove what a line added) — and loads it into the snippet box. Where it can't know the original value (a changed hostname, a set password, a rewritten description) it writes a "! MANUAL: …" comment naming the line instead of guessing. Nothing is sent: you review the draft, resolve the MANUAL lines, and push it yourself (so the same read-only/destructive gating applies). Cisco IOS style. It reverses the LAST push (or the lines that applied before a stop).

Credentials: passwords and passphrases you type at a prompt are held in memory for the session only — never written to disk. (A saved host's password is the one you chose to store, kept encrypted.) If a command's own text carries a credential ("enable secret ...", "username admin secret ...", "snmp-server community ..."), the Activity log masks the value with asterisks so the log stays readable without storing the secret in plaintext.

Reading results: command output appears in the console. All three transports are a real persistent shell (SSH runs an actual PTY, not one-shot exec) — enable prompts, --More-- paging, and multi-step config wizards all carry state between commands the way a real terminal session does.