CCNA online course

Secure Shell (SSH) Protocol

Learn how SSH securely provides remote command-line access to routers and hosts, how SSH clients and servers work, and why SSH is safer than Telnet.

Secure Shell (SSH) is a protocol for securely accessing and administering a remote host or network device across an IP network. After the SSH connection is established and the administrator authenticates, the administrator can run commands on the remote device as if working from its local command line.

SSH is commonly used for secure remote management of routers, switches, servers, and other networked systems. It protects login credentials and management commands from being read by someone who captures the traffic.

What SSH Does

Remote management means administering a device from another host over a network. SSH provides a protected command-line session for this purpose.

1. The administrator starts an SSH client.
2. The client identifies the destination by an IP address or hostname.
3. The client connects to the SSH server on the destination device.
4. The endpoints negotiate security parameters and establish protected session keys.
5. The administrator authenticates, usually after receiving a login prompt.
6. The administrator runs commands on the remote device.

SSH does not make the remote device local. Instead, it securely transports the administrator's input and the device's responses across the network.

SSH Client and SSH Server Roles

An SSH client is software on the administrator's machine that initiates an SSH connection. A command-line program named ssh is a common client. A graphical application such as PuTTY can also act as an SSH client.

An SSH server is a service running on the destination host or network device. It listens for SSH connections, performs secure-session negotiation, handles authentication, and provides the remote command-line session.

The client-to-server relationship is directional at the start: the workstation's SSH client initiates the connection, and the managed device's SSH server accepts it.

SSH Compared with Telnet

Telnet is an older remote terminal protocol. It provides remote command-line access, but it does not protect session data with encryption. If an attacker performs eavesdropping, meaning unauthorized observation or capture of network traffic, usernames, passwords, commands, and device responses may be readable.

SSH protects the session with encryption. This makes credentials and command traffic difficult to read when captured, so SSH is the appropriate choice for secure remote administration.

SSH Encryption and Cryptography

Encryption converts data into a protected form so intercepted traffic cannot be readily read. SSH uses two broad types of cryptography for different jobs.

Public-key cryptography

Public-key cryptography, also called asymmetric cryptography, uses a related public key and private key. SSH uses public-key techniques during secure connection establishment and identity verification. For example, the client can verify the identity of the SSH server by checking its host key.

Asymmetric operations provide useful security properties for starting the connection, but they are comparatively resource-intensive. SSH therefore does not normally use public-key operations to encrypt every byte of a long interactive session.

Symmetric session encryption

During secure negotiation, the endpoints establish or derive a shared symmetric key. The same session key, or corresponding symmetric keys, is used efficiently to protect ongoing traffic in both directions.

The functional distinction is:

• Asymmetric cryptography: supports secure setup and identity verification.
• Symmetric encryption: efficiently protects the commands, credentials, and device responses exchanged during the session.

Authentication and encryption are related but different. Encryption protects the data in transit, while authentication confirms that the user and, depending on the checks performed, the destination are authorized or trusted.

SSH Connection Process

1. Launch the client: The administrator opens a command-line SSH program or a graphical client such as PuTTY.
2. Identify the target: The administrator enters the destination's IP address or hostname.
3. Connect to the server: The client attempts to reach the SSH service using TCP.
4. Negotiate security: The endpoints agree on compatible algorithms, verify or exchange key information, and establish or derive symmetric session keys.
5. Authenticate: The administrator provides the requested username and authentication credentials. A login prompt is presented as the secure connection setup proceeds.
6. Manage the device: After successful authentication, commands and responses travel through the encrypted session.

A successful session requires both network reachability and an available SSH service. A correct username and password alone cannot create a session if the target address cannot be reached or TCP port 22 is blocked.

TCP and Port 22

SSH uses TCP, a transport protocol that provides a reliable, connection-oriented communication stream. The default well-known SSH port is TCP port 22.

The client normally connects to the server's IP address on port 22. Firewalls, access-control lists, and other filters must permit the connection. An administrator may configure a service to use another port, but port 22 is the standard default and is the value normally expected in introductory networking scenarios.

Example: Host A Managing Router R1

In this scenario, an administrator uses Host A to manage router R1. R1 has the IP address 10.0.0.1.

• Host A runs the SSH client.
• R1 runs the SSH server.
• The client targets 10.0.0.1.
• The connection uses TCP port 22.
• The administrator authenticates after secure negotiation.
• Router commands are sent through the encrypted SSH session.

From a command-line SSH client, the administrator could initiate the connection with:

ssh <username>@10.0.0.1

In a graphical client such as PuTTY, the essential connection values are:

Host: 10.0.0.1
Protocol: SSH
Port: 22

After the client connects, the administrator receives the appropriate login prompt. Once authentication succeeds, commands issued for R1 are carried in the protected session rather than being sent as readable Telnet traffic.

Troubleshooting SSH Connections

The SSH client cannot connect

• Confirm IP reachability to the target address.
• Verify that the SSH server is enabled on the destination device.
• Verify that TCP port 22 is permitted by intervening firewalls, filters, and device access controls.
• Confirm that the client is using the correct IP address or hostname.

The connection reaches the device, but authentication fails

• Confirm the username and authentication credentials.
• Confirm that the account is permitted to use remote SSH access.
• Verify that the administrator is connecting to the intended device.
• Check whether the device requires a different authentication method or account policy.

Someone suggests Telnet because it seems easier

Ease of connection does not make Telnet safe. Explain that Telnet sends credentials and commands without encryption, so an observer may capture readable session data. Use SSH for remote management wherever secure access is required.

Key Points to Remember

• SSH is a secure remote-access protocol for administering hosts and network devices.
• The SSH client runs on the administrator's workstation and initiates the connection.
• The SSH server runs on the managed device and accepts the connection.
• SSH uses public-key cryptography during secure setup and identity verification.
• SSH uses a symmetric session key to efficiently protect ongoing traffic.
• SSH uses TCP, with TCP port 22 as its default well-known port.
• Telnet provides remote access without encryption and can expose credentials and commands to eavesdroppers.

For related foundations, review the client-server networking model, password configuration in Cisco IOS, and OSI reference model.