VMware ESXi and vSphere Cluster Management

What Is Secure Shell (SSH)? Secure Remote Device Management

Learn how SSH securely manages routers, switches, and servers, how it compares with Telnet, and how to configure and verify SSH on Cisco IOS.

What Is Secure Shell (SSH)?

Secure Shell (SSH) is an application-layer protocol and software ecosystem for securely accessing, administering, and running commands on a remote device. It is commonly used to manage routers, switches, servers, firewalls, and other networked systems from a command line.

SSH uses a client-server model. An SSH client runs on the administrator's computer and initiates a session. An SSH server runs on the target device and accepts, authenticates, and manages that session. For example, a workstation can use an SSH client to connect to a router's SSH server at its management address.

After a successful login, an authorized administrator may enter operational commands, inspect status, view logs, change configuration, or perform other tasks allowed by the device's authorization policy. SSH is primarily used for secure command-line remote management, not ordinary web browsing.

Why Remote Access Must Be Protected

Management traffic may cross shared networks, wireless links, service-provider infrastructure, or other networks that administrators do not fully control. If a remote terminal protocol sends information as plaintext, also called clear text, anyone able to capture the traffic may be able to read it.

• Credentials: Usernames and passwords may be exposed and reused to access other systems.
• Commands: Attackers may learn how the device is configured or use captured commands to understand administrative activity.
• Device output: Addresses, routes, usernames, logs, and configuration details may reveal useful information.
• Eavesdropping: An unauthorized observer can inspect traffic while it crosses the network.
• Credential theft: Stolen credentials can allow an attacker to impersonate an administrator.

Secure management should also follow least privilege: each administrator receives only the permissions needed for the job. Use unique named accounts rather than shared credentials so actions can be attributed to a person. Authentication verifies identity, authorization controls permitted actions, and accounting or logging records administrative activity.

How SSH Protects a Session

SSH protects the session through encryption established during connection setup. Encryption transforms readable information into data that unauthorized observers should not be able to understand. This protects login credentials, commands, and returned device output while the session is active.

Core Security Properties

• Confidentiality: Session contents are encrypted so an observer cannot normally read them from a packet capture.
• Integrity: Protection mechanisms help detect data altered while in transit.
• Peer authentication: The client can verify that it is communicating with the expected SSH server, and the server authenticates the user.

SSH uses asymmetric cryptography, also called public-key cryptography, during setup. This uses related public and private keys. SSH then establishes shared symmetric session keys, which efficiently encrypt the ongoing conversation. The setup process that establishes shared cryptographic material is called key exchange.

Host Keys and Fingerprints

An SSH server has a host key, which helps identify that server to clients. A client may display a short identifier derived from the host key, called a host fingerprint, the first time it connects. The client may ask whether the user wants to accept and save that identity.

In a production environment, validate the fingerprint through a trusted channel, such as device documentation, a controlled management system, or an administrator who can verify the device directly. Do not accept a changed fingerprint blindly. A changed key may result from a legitimate device replacement or regenerated keys, but it can also indicate an interception attempt.

SSH Compared with Telnet

Telnet is an older remote terminal protocol. Like SSH, it can provide command-line access, but Telnet normally sends session data without encryption. A Telnet packet capture can therefore expose readable usernames, passwords, commands, and output.

In an authorized lab, a conceptual packet comparison demonstrates the difference: Telnet session data may appear readable, while normal SSH session contents appear encrypted. Packet inspection must always be performed only with permission.

When migrating a device from Telnet-only virtual terminal access, configure and test SSH first from an approved management location. Then configure the VTY lines to accept SSH and reject Telnet with transport input ssh. Keep a tested console or out-of-band recovery path so a configuration mistake does not lock out administrators.

SSH Connection Workflow

1. Launch an SSH client.
2. Enter the destination as an IPv4 address, IPv6 address, or resolvable hostname. For example, the router's management address may be 10.0.0.1.
3. The client attempts a TCP connection to port 22 unless another port is configured.
4. The client and server negotiate protocol and algorithm choices, exchange key material, and verify the server identity.
5. The administrator authenticates with a password, public key, or a centralized authentication service.
6. The server provides a remote shell or management session with permissions determined by device configuration.

A nondefault TCP port can be used in some environments, but changing the port is not a replacement for authentication, authorization, encryption, and access controls.

SSH Authentication Methods

Username and Password

With password authentication, the administrator supplies a username and password. The SSH session protects the exchange in transit, but password quality, account security, and rate limiting still matter. Use unique named administrator accounts instead of one shared login.

Public-Key User Authentication

Public-key authentication uses a user key pair: a private key remains on the administrator's system, while the corresponding public key is installed or registered on the server. The client proves possession of the private key without sending that private key to the server.

Public-key user authentication is distinct from the server's host key. The host key identifies the server to the client; a user key authenticates an administrator to the server. Key-based access can reduce password exposure and support stronger access practices, but private keys must be protected with appropriate file permissions and, preferably, a passphrase.

Centralized Authentication

Organizations may use AAA systems, such as RADIUS or TACACS+, to centralize authentication, authorization, and accounting. Centralization supports consistent policies and auditing, but the device should have an approved fallback method for emergencies and loss of service.

TCP Ports, Transport, and Addressing

• TCP port 22: The well-known default transport port for SSH.
• Destination address: An IPv4 address, IPv6 address, or hostname that resolves to the management endpoint.
• Management IP: The reachable address used to access the device's management service; it is not a separate device.
• Alternate port: Some environments configure SSH on a different TCP port. This may reduce casual scanning noise, but it does not provide security by itself.

Configuring SSH on Cisco IOS

The exact commands and requirements vary by IOS release and platform. The foundational local-authentication example below requires a hostname, domain name, local user credentials, and generated RSA keys. Use a strong secret in place of the placeholder.

enable
configure terminal
hostname R1
ip domain-name example.local
username netadmin privilege 15 secret <strong-secret>
crypto key generate rsa modulus 2048
ip ssh version 2
line vty 0 4
 login local
 transport input ssh
end
copy running-config startup-config

• The hostname and domain name provide device identity information used when generating keys on many IOS versions.
• crypto key generate rsa modulus 2048 creates an RSA key pair. The supported modulus and syntax depend on the platform and software.
• ip ssh version 2 prefers SSH version 2.
• login local tells the VTY lines to use locally configured usernames.
• transport input ssh permits SSH and rejects Telnet on those VTY lines.
• Configure every applicable VTY range if the device supports more than lines 0 through 4.
• copy running-config startup-config saves the configuration for use after a reboot.

Optional Source Restriction

Restrict management access to approved source networks with an ACL. Adapt the network to the actual management design and test carefully to avoid locking out authorized administrators.

ip access-list standard MGMT-SOURCES
 permit 10.0.0.0 0.0.0.255
line vty 0 4
 access-class MGMT-SOURCES in
 transport input ssh

Connecting from an SSH Client

Command-Line Client

From an OpenSSH-style client, specify the username and destination:

ssh netadmin@10.0.0.1
ssh -p 22 netadmin@10.0.0.1

The second command explicitly selects the default port and is useful for learning how a client chooses a destination port. A first connection may display a host-key fingerprint and ask whether to continue. Validate that fingerprint through a trusted channel before accepting it in production.

After successful login, indicators may include a device prompt such as R1> or R1#. The prompt and available commands depend on the device and privilege level.

Graphical SSH Clients

A graphical client commonly asks for:

• Host name: The management IP address or resolvable hostname.
• Port: Usually 22.
• Connection type: SSH rather than Telnet.
• Username: The named administrator account.
• Saved session: An optional profile for approved, reusable connection settings.

Never store secrets in an unsecured saved session. Redact passwords, private keys, and other sensitive values when documenting or demonstrating a connection.

Verifying SSH on Cisco IOS

Use these commands to inspect SSH status, active sessions, users, and VTY settings:

show ip ssh
show ssh
show users
show running-config | section line vty
show running-config | include username|ip domain-name|ip ssh

• show ip ssh displays SSH configuration and version information.
• show ssh displays active SSH sessions and related details.
• show users shows users connected to the device.
• The VTY section confirms local login and SSH-only transport settings.
• The filtered configuration confirms identity, local-user, and SSH settings.

Operational Verification and Hardening

• Verify the device is reachable at the intended management address.
• Confirm SSH is enabled and accepting connections on the expected VTY lines.
• Use SSH version 2 and disable Telnet access.
• Restrict source addresses with an ACL or equivalent management-plane policy.
• Use strong credentials or protected public keys.
• Apply authorization controls and least privilege.
• Configure idle session timeouts and appropriate login protections.
• Enable logging and accounting so administrative activity can be reviewed.
• Prefer a dedicated management network or management interface when available.

SSH secures the SSH management session. It does not automatically secure every other protocol or service running on the device. Web management, file transfer, monitoring, APIs, and other services require their own appropriate security controls.

Common SSH Failures and Troubleshooting

Cisco-Specific Configuration Failures

If a Cisco device does not accept SSH, check for a missing hostname, absent domain name, missing RSA keys, unsupported SSH version, or VTY lines that allow only Telnet. Use show ip ssh and the running-configuration commands above to identify which prerequisite is absent.

Practical Example: Administrator Connects to a Router

1. The administrator's workstation runs an SSH client.
2. The client targets router R1 at management address 10.0.0.1.
3. The client opens a TCP connection to port 22.
4. R1 presents its host key, and the administrator verifies the fingerprint.
5. The client and R1 negotiate compatible algorithms and establish session keys.
6. The administrator authenticates as netadmin.
7. R1 grants the commands allowed by the account's privilege and authorization policy.

The administrator can now run authorized router commands without exposing the login exchange or session contents as clear text.

Practical Example: A Changed Host Key

Suppose an SSH client reports that the server host key differs from the identity saved for 10.0.0.1. Legitimate explanations include replacing the router, regenerating its keys, or assigning the address to a different approved device. A malicious explanation could be an interception attempt.

Confirm the device identity and fingerprint through a trusted channel before removing or replacing the saved key. Do not disable host-key checking merely to make the warning disappear.

Exam- and Practice-Relevant Notes

• SSH and Telnet both support remote command-line access, but SSH protects the session and Telnet normally sends it in clear text.
• SSH uses TCP port 22 by default; Telnet uses TCP port 23.
• The SSH client initiates the connection; the SSH server accepts it on the managed device.
• Server host keys identify the server to the client. User public keys authenticate a user to the server.
• On Cisco IOS, a common foundational sequence is identity settings, local user, RSA keys, SSH version 2, local VTY login, and SSH-only transport.
• A successful TCP connection does not prove that authentication will succeed. Reachability, service availability, negotiation, and credentials are separate troubleshooting stages.

For a concise related reference, see What Is Secure Shell (SSH)?