Connecting to a Device with Netmiko

Opening a connection

ConnectHandler is the function that actually opens the SSH session. It takes the connection parameters from the last lesson and returns a connection object you can run commands on:

connect_example.py

from netmiko import ConnectHandler

device = {
  "device_type": "cisco_ios",
  "host": "192.168.1.1",   # placeholder — use your own lab device's IP
  "username": "labuser",   # placeholder — never a real credential
  "password": "labpass",   # placeholder — see the next section for the real way to do this
}

connection = ConnectHandler(**device)
print("Connected.")

connection.disconnect()
print("Disconnected.")

**Never run this with real credentials written in the file.** This example exists to show the shape of the call — the next section replaces the hardcoded username/password with a safe runtime prompt.

**device unpacks the dictionary into the keyword arguments ConnectHandler expects — the same dictionary-unpacking shape, just applied to a function call instead of a data structure.

The connection lifecycle

Build connection parametersdevice_type, host, username, password
ConnectHandler(**device)opens the SSH session
Authenticatedevice checks the credentials
Session openready to send commands
disconnect()closes the session cleanly

Always close what you open

A connection left open holds a resource on the device — Cisco switches have a limited number of concurrent SSH sessions (VTY lines). A script that connects to fifty devices and never disconnects can genuinely lock other engineers out of a device. Calling disconnect() when you're done isn't optional cleanup — it's part of doing this correctly.

Quick checkConcept check

Why does a script need to call connection.disconnect() when it's finished, rather than just letting the script end?

It doesn't matter — Python cleans up connections automatically the instant a script endsAn open SSH session holds a limited device resource (a VTY line) — leaving it open can prevent other sessions, including other engineers, from connectingdisconnect() is only needed for configuration changes, not show commandsIt's purely a style preference with no real effect

Supplying credentials safely

Never write a real username or password directly into a script. Two safe, standard ways to supply them at runtime instead:

credentials_getpass.py

import getpass
from netmiko import ConnectHandler

username = input("Username: ")
password = getpass.getpass("Password: ")

device = {
  "device_type": "cisco_ios",
  "host": "192.168.1.1",   # placeholder
  "username": username,
  "password": password,
}

connection = ConnectHandler(**device)

input() prompts for the username in plain text; getpass.getpass() prompts for the password without echoing it to the screen — the same behavior as a terminal login prompt. Nothing is ever written to a file.

credentials_env.py

import os
from netmiko import ConnectHandler

device = {
  "device_type": "cisco_ios",
  "host": "192.168.1.1",   # placeholder
  "username": os.environ["NETMIKO_USERNAME"],
  "password": os.environ["NETMIKO_PASSWORD"],
}

connection = ConnectHandler(**device)

os.environ reads values set outside the script — in the terminal session or a scheduler's configuration, never written into the code itself. This is the better fit for a script that runs unattended, on a schedule, without anyone at the keyboard to type a password.

Quick checkIdentify the correct code

Which line correctly reads a password without echoing it to the screen?

password = input("Password: ")password = getpass.getpass("Password: ")password = "mypassword"password = os.getpass("Password: ")

Quick checkMyth check

Is it acceptable to put a real device's username and password directly into a devices.csv inventory file, as long as the file stays on the engineer's own laptop?

Yes — if only one person has access, it's safeNo — credentials should never be written into an inventory file at all, regardless of who has access to itYes, but only for lab devices, never productionNo, but only if the laptop has a strong password

Quick checkScenario

A script needs to run unattended every night on a schedule, with no one available to type a password. Which credential method fits better — getpass() or environment variables?

getpass() — it's the more secure option in every caseEnvironment variables — they don't require anyone to be present to type anything when the script runsNeither works for unattended scriptsIt doesn't matter, they're interchangeable in every situation

What can go wrong when connecting

safe_connect.py

from netmiko import ConnectHandler, NetmikoTimeoutException, NetmikoAuthenticationException

try:
  connection = ConnectHandler(**device)
except NetmikoTimeoutException:
  print(f"{device['host']}: did not respond — check the IP and network path")
except NetmikoAuthenticationException:
  print(f"{device['host']}: rejected the credentials")

Two distinct exceptions for two distinct problems. A timeout means the device never answered at all — wrong IP, no route, or it's down. An authentication failure means it answered, but didn't accept the username or password.

What a real timeout actually looks like

Testing this against a guaranteed-unreachable address confirms Netmiko's real behavior: a connection attempt to an address with nothing listening raises NetmikoTimeoutException with a message that starts "TCP connection to device failed" and lists likely causes — wrong hostname/IP, wrong port, or a firewall in the way. That's exactly the category of problem a timeout signals: the network path itself, not the credentials.

Quick checkConcept check

A connection attempt raises NetmikoAuthenticationException. What does this tell you, compared to NetmikoTimeoutException?

The device never responded at allThe device was reachable and responded, but rejected the username or passwordThe device's IP address is wrongThere's no meaningful difference between the two exceptions

Key takeaways

ConnectHandler(**device) opens the SSH session; connection.disconnect() closes it — always close what you open.
getpass() and input() prompt for credentials interactively; environment variables supply them for unattended, scheduled scripts — neither ever writes a credential into a file.
NetmikoTimeoutException means the device never responded (a network-path problem); NetmikoAuthenticationException means it responded but rejected the credentials — different problems, different responses.
This lesson's try/except around ConnectHandler is the beginning of the real connection/check function this module is building — the same shape as Phase 2.6's try/except around simulate_connection().

What you'll learn

Opening a connection

The connection lifecycle

Supplying credentials safely

What can go wrong when connecting