SSH to Cisco Gear from a Mac or Linux Terminal (No PuTTY Needed)
If you have ever watched a Windows colleague hunt down and install PuTTY, here is some good news: on a Mac or a Linux box you never have to. Every current version of macOS and every mainstream Linux distribution ships with OpenSSH — the same battle-tested client that runs on the servers you are learning to manage — already installed. Open Terminal, type one command, and you are on the router. Whether you are consoled into physical gear on a bench or reaching a node inside a Cisco Modeling Labs topology that already has a management IP, the workflow from a Unix terminal is the same. This guide covers the handful of commands that get you connected, and the two or three errors that reliably trip people up when the far end is an older Cisco image or a freshly rebuilt lab node — and, just as importantly, why each one happens so the fix is not just a magic incantation.
Part of the Device Security & SSH learning hub
Open Terminal and connect — SSH or Telnet
The client is already there, so there is nothing to download. To reach a device at 10.0.0.1 as the user admin, run `ssh admin@10.0.0.1`. The `user@host` form and the older `-l` (login) form are exactly equivalent — `ssh -l admin 10.0.0.1` does the same thing — so pick whichever reads better in your shell aliases and scripts.
The first time you connect to a given device, OpenSSH shows its host key fingerprint and asks you to confirm. Type `yes` and it records that key in `~/.ssh/known_hosts` so it can recognize the device next time. Hold on to that detail — it is the reason for the alarming warning covered further down.
Telnet still has a place in lab work, but treat it as a bring-up tool, not a remote-access protocol. It carries everything, including your password, in clear text, so it never belongs on a real network. On an isolated lab, though, a device that has not yet had SSH enabled will only answer on Telnet or the physical console, so `telnet 10.0.0.1` is often how you reach a brand-new node to configure it in the first place.
One catch: modern macOS and many Linux distributions no longer install a Telnet client by default (Apple removed it years ago). If `telnet` reports 'command not found', add it from your package manager — for example `brew install telnet` on a Mac with Homebrew, or `sudo apt install telnet` / `sudo dnf install telnet` on Linux.
# Connect over SSH (encrypted) — two equivalent forms
ssh admin@10.0.0.1
ssh -l admin 10.0.0.1
# Telnet to a lab device (clear text; may need installing first)
telnet 10.0.0.1Fixing "no matching key exchange method" on older IOS
Sooner or later you will SSH to an older IOS device and get slapped with 'Unable to negotiate ... no matching key exchange method found' or 'no matching host key type found'. This is not a bug and it is not your device being broken — it is your client being cautious. Recent OpenSSH (9.0 and up) dropped the SHA-1-based key-exchange algorithm `diffie-hellman-group14-sha1` and the `ssh-rsa` host-key signature algorithm from its defaults because SHA-1 is considered broken. Older Cisco images often offer nothing newer, so the two sides find no common ground and the handshake fails before you ever see a password prompt.
The fix is to re-enable those legacy algorithms for the connection that needs them. The leading `+` in each `-o` value is the important part: it appends the algorithm to OpenSSH's existing default set rather than replacing it. If you dropped the `+`, you would restrict the session to only that one algorithm and likely break other connections.
If the error mentions the cipher instead (some very old images only offer CBC ciphers like `aes256-cbc`), extend that list the same way with `-o Ciphers=+aes256-cbc`. And if you find yourself typing these flags all day, put them in `~/.ssh/config` scoped to your lab subnet so they apply automatically.
A word of caution that matters for the exam mindset as much as security: these algorithms are disabled by default precisely because they are weak. Re-enable them for gear you control on an isolated lab, but do not carry that config over to production or internet-facing hosts.
# Re-enable the legacy algorithms old IOS still negotiates
ssh -o KexAlgorithms=+diffie-hellman-group14-sha1 \
-o HostKeyAlgorithms=+ssh-rsa admin@10.0.0.1
# If it also complains about the cipher, extend that list the same way
ssh -o KexAlgorithms=+diffie-hellman-group14-sha1 \
-o HostKeyAlgorithms=+ssh-rsa \
-o Ciphers=+aes256-cbc admin@10.0.0.1
# ~/.ssh/config — make it automatic for a lab subnet
# Host 10.0.0.*
# KexAlgorithms +diffie-hellman-group14-sha1
# HostKeyAlgorithms +ssh-rsaThe alarming host-key warning after a key regen
One day a connection you have made a hundred times greets you with a wall of hashes and 'WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!', and OpenSSH flatly refuses to continue. This is the flip side of that first-connect fingerprint prompt. SSH uses a trust-on-first-use model: it recorded the device's host key in `~/.ssh/known_hosts`, and it compares against that record every time afterward. A key that suddenly does not match can mean someone is impersonating the device, so the client fails loud rather than quietly connecting you to an impostor.
In a lab, the cause is almost always innocent. You regenerated the device's crypto keys, reloaded a node back to defaults, or reused the same IP address for a different device — any of which legitimately changes the host key. The warning is doing its job; it simply has no way to know the change was intentional.
Clear the stale entry with `ssh-keygen -R 10.0.0.1`, which removes just that host's line from `known_hosts`. Your next connection will prompt you to accept the new key, exactly like a first-time connection. Only run this when you actually know why the key changed — on a production network, an unexplained host-key change is a signal worth investigating, not silencing.
# Clear the stale fingerprint after a device regenerates its key
ssh-keygen -R 10.0.0.1Serial consoles and logging your session
SSH and Telnet only work once a device has an IP address and something listening on it. Before that — initial config, a wiped node, a router that will not boot — you need the serial console. A USB-to-serial adapter shows up on your machine as a device file: on macOS it is typically `/dev/tty.usbserial*` (run `ls /dev/tty.*` to find the exact name), and on Linux it is usually `/dev/ttyUSB0` or `/dev/ttyACM0`.
On a Mac, `screen /dev/tty.usbserial 9600` attaches to that port. The 9600 is the baud rate — Cisco's console default is 9600 8N1 (8 data bits, no parity, 1 stop bit, no flow control). One thing that traps newcomers: to leave `screen`, press Ctrl-A then `\` (or Ctrl-A then K to kill the window); closing the Terminal tab alone can leave the session hanging. On Linux, `minicom -D /dev/ttyUSB0 -b 9600` does the same job, and `screen` works there too if you prefer it.
Finally, capture your work. Piping SSH through `tee` writes a copy of everything you see to a file while you still watch it live — `ssh admin@10.0.0.1 | tee session.log` — which is handy for documenting a lab or keeping a record of the commands you ran and their output. For a fuller transcript that also captures an interactive serial session, `script session.log` records the whole terminal until you type `exit`.
# macOS: attach to a USB serial console at 9600 8N1
screen /dev/tty.usbserial 9600 # Ctrl-A then \ to quit
# Linux: same idea with minicom (or: screen /dev/ttyUSB0 9600)
minicom -D /dev/ttyUSB0 -b 9600
# Save everything you see to a file while you work
ssh admin@10.0.0.1 | tee session.logFrequently asked questions
Can I SSH into Cisco Packet Tracer devices from my Mac terminal the same way I do with CML nodes?
No. Packet Tracer is a self-contained simulator whose devices are not exposed to your host operating system, so the ssh client in your terminal cannot reach them — you use Packet Tracer's own built-in terminal instead. Cisco Modeling Labs runs each node as a real virtual machine with a routable management IP, which is exactly why your Mac or Linux OpenSSH client can connect to it like physical gear. Packet Tracer still has its place because it can grade you inside pre-authored .pka activities.
What do I actually need installed to run CML on a Mac or Linux laptop in the first place?
CML ships as a virtual appliance (an OVA or ISO) that runs inside a hypervisor, not as a native desktop application you double-click to install. VMware Workstation and Fusion, which are now free for personal use, are the supported host, whereas VirtualBox is not a supported CML platform. Confirm the current licensing terms and version requirements before you build, since Cisco changes both fairly often.
SSH works for my instructor but mine is refused even though the console works fine — what is missing on the router?
A working console with refused SSH almost always means the device side is not fully set up: SSH needs a hostname, an ip domain-name, locally generated RSA keys, a local username, and transport input ssh under the vty lines. Remember that crypto key generate rsa is an EXEC command, not a config line, and it silently fails if no ip domain-name has been set first. Also confirm you actually have IP reachability to the management address before blaming the SSH config.
Can I set up passwordless key login to Cisco routers with ssh-copy-id like I do on Linux servers?
Not with ssh-copy-id, because that tool appends your key to a Unix authorized_keys file that IOS does not have. IOS does support SSH public-key authentication, but you install the key under ip ssh pubkey-chain on the device rather than copying it over, and most lab workflows simply use a username and password instead. Password authentication over SSH is still fully encrypted, so it is perfectly fine for study and exam practice.
The telnet command is missing on my Mac — how do I reach a Telnet-only lab node?
Recent macOS releases removed the bundled telnet binary, so you may get command not found even though ssh works normally. You can install it with Homebrew (brew install telnet) or fall back to nc host 23 for a quick cleartext session. The better fix is to enable SSH on the node, since Telnet sends your credentials in the clear and disabling it is standard CCNA best practice.
Practice this on graded Cisco labs
Reading is step one — build Device Security & SSH on real Cisco IOS and grade your own config, or try a free sample lab first.