Console (SSH / Telnet / Serial)

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.

Telnet: 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). WARNING: Telnet is UNENCRYPTED — your credentials and every keystroke cross the network in clear text. Use it only when SSH isn't available, and prefer a trusted or console/management network; switch the device to SSH as soon as you can.

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. Read-only "show" commands are safe; config changes are not — read-only mode blocks them until you opt in.

Passwords and passphrases you type are only ever held in memory for the session — SubnetSlinger never writes them to disk. 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.