Serial console
Definition
Serial console — A serial console is a UART/COM-based terminal session; PuTTY can open serial lines for device recovery and embedded work.
In SSH administration, precise vocabulary prevents costly mistakes: operators who confuse host keys with user keys, or SCP with SFTP, often “fix” the wrong layer and leave the real misconfiguration untouched. This glossary entry is written for PuTTY users on Windows who need the practical client-side meaning, not a standards-committee reprint.
Independent resource: Putty.info is not affiliated with the official PuTTY project. For normative protocol text, use IETF documents and the official PuTTY manual.
How it appears in PuTTY
In PuTTY, “Serial console” influences how you configure Session, Connection → SSH, Auth, Tunnels, or companion tools (PuTTYgen, Pageant, PSCP, PSFTP, Plink). Prefer saved sessions so the setting remains reproducible across reconnects.
When you open the PuTTY configuration window, category names in the left tree map directly onto these concepts. Session stores host and port; Connection → SSH controls protocol behaviour; Connection → SSH → Auth attaches user keys; Connection → SSH → Tunnels defines forwards; Window and Terminal affect display only and never replace cryptography settings.
Practical workflow notes
When applying “Serial console” operationally, write down the intended hostname, whether a bastion is involved, and which credential identity you expect to use. Test on a non-production endpoint first. If behaviour differs between two PCs, compare PuTTY versions (Help → About), Pageant state, and the saved session exports rather than guessing.
Operators who treat glossary terms as trivia miss the operational edge: naming the layer correctly decides whether you change DNS, firewall rules, sshd_config, authorized_keys, or only a PuTTY saved session. Keep a short lab checklist beside each term—hostname, port, username, key identity, and whether a bastion is in path—so handoffs between teammates do not reinvent the same failure. When documentation conflicts with what you see in Help → About, prefer the behaviour of your installed version and cross-check the official HTML manual rather than memorizing screenshots from older articles.
- Save a named session after the setting works so you can bisect later changes.
- Document the hostname, port, username, and key path beside the term in your runbook.
- Re-read host-key prompts carefully—accepting the wrong fingerprint trains your client to trust an impostor.
- Prefer passphrase-protected private keys and Pageant for interactive work instead of unprotected files on disk.
- Validate behaviour on a non-production host before rolling the same pattern to critical infrastructure.
- Record whether agent forwarding or tunnels were enabled; those settings change the threat model even when the definition of the term stays constant.
Common mistakes and clarifications
These misunderstandings show up repeatedly in support threads and incident reviews:
- Treating “Serial console” as interchangeable with unrelated SSH ideas (especially host keys vs user keys, or SCP vs SFTP).
- Changing multiple PuTTY categories at once so root cause cannot be isolated.
- Accepting host-key prompts without out-of-band verification when something looks “almost right.”
- Storing unencrypted private keys in shared folders because a tutorial skipped passphrases.
- Following third-party download mirrors for tools instead of official PuTTY packages.
Educational examples on Putty.info use hosts such as example.com and documentation addresses from TEST-NET ranges. Replace them with your inventory; never treat sample IPs as live systems.