What Is SSH in Networking?
This page mentions older exam versions. See the Current Exam Context and Legacy Exam Context sections below for the updated mapping.
On This Page
Quick Definition
SSH is a way to securely connect to another computer over the internet, like a remote control that lets you type commands on a distant server. It creates a protected tunnel so that passwords, files, and data cannot be read by eavesdroppers. SSH replaces older insecure tools like Telnet and is widely used by IT professionals to manage servers, network devices, and cloud infrastructure.
Commonly Confused With
Telnet also provides remote shell access, but it sends all data in plaintext, including passwords. SSH encrypts the entire session. Telnet uses TCP port 23, while SSH uses TCP port 22. Telnet is considered obsolete for secure environments.
If you use Telnet to log into a server, someone on the same network can capture your password. With SSH, that password is encrypted and safe.
SSL/TLS is used for encrypting web traffic (HTTPS), email, and other application-layer protocols. SSH is primarily for remote shell access and tunneling. Both use cryptography, but SSL/TLS relies on certificates from public Certificate Authorities, while SSH typically uses self-generated key pairs.
When you visit a website with HTTPS, SSL/TLS protects your connection. When you SSH into a server, you are using SSH's own encryption, not SSL/TLS.
SFTP is a subsystem of SSH that provides file transfer over an encrypted connection. It is often confused with FTP, but FTP is not encrypted. SFTP uses the same authentication and encryption as SSH, making it secure. It is not a separate protocol but a feature of SSH.
To upload a file securely to a server, you use an SFTP client that connects via SSH, whereas regular FTP sends your password in plaintext.
A VPN creates an encrypted tunnel for all network traffic from a device to a remote network, making it appear as if the device is local. SSH creates an encrypted tunnel for specific connections (like a shell or a single port). SSH is simpler to set up but only protects specific traffic, not the entire device.
A VPN allows you to access the company internal website and file shares as if you were in the office. SSH lets you run a single command on a remote server or forward one port.
Must Know for Exams
SSH appears across many IT certification exams, often as a core topic. In CompTIA A+ (220-1101), you may encounter questions about SSH as a secure alternative to Telnet for remote management of switches and routers. The exam tests your ability to identify port numbers (22 for SSH, 23 for Telnet) and understand basic encryption concepts.
For CompTIA Network+ (N10-008), SSH is more prominent. Objectives cover SSH for secure remote access, key-based authentication, and its role in network device management. You may see scenario-based questions where you must choose between SSH and less secure protocols like Telnet or FTP. Questions also test understanding of SSH as a secure replacement for rlogin, rsh, and rcp.
CompTIA Security+ (SY0-601) dives deeper into SSH's cryptographic foundations. You need to understand how SSH provides confidentiality, integrity, and authentication. Exam questions may involve public key infrastructure concepts as they relate to SSH host keys, or the use of SSH tunnels for secure communications. Port forwarding with SSH is sometimes tested in scenarios about secure access to internal services.
In Linux+ (XK0-005), SSH is tested heavily. You must know how to configure the SSH daemon (sshd), manage keys in ~/.ssh/authorized_keys, use ssh-keygen to generate keys, set file permissions correctly, and troubleshoot connection issues. Configuration directives like PermitRootLogin, PasswordAuthentication, Port, and AllowUsers are common exam topics. Questions may ask you to identify why an SSH connection fails based on log output or verify that key permissions are correct.
For Cisco CCNA (200-301), SSH is essential for managing switches and routers securely. You must configure SSH on a Cisco device, including generating RSA keys, setting a domain name, creating local users, and applying SSH to VTY lines. The exam tests step-by-step configuration and troubleshooting of SSH, especially when Telnet is disabled.
AWS Certified Solutions Architect Associate and SysOps Administrator also include SSH scenarios, such as accessing EC2 instances securely using key pairs. You need to understand how SSH key pairs work with AWS, the importance of setting proper permissions on .pem files, and how to use SSH agent forwarding for bastion hosts. While not a core focus, SSH knowledge supports several exam objectives in cloud security and operational excellence.
Simple Meaning
Think of SSH as a secure, private phone line between your computer and a remote server. When you use the internet normally, your data can be intercepted by anyone along the route, much like shouting across a crowded room. SSH wraps your communication in a strong encrypted envelope, so even if someone intercepts the data, they only see gibberish.
Imagine you are a bank manager who needs to open the vault from home. You could shout the combination over the phone, but anyone listening would hear it. Instead, you call your security guard, speak in a secret code only you two understand, and the guard opens the vault. SSH does exactly that for computer commands and data.
SSH uses a pair of digital keys: a public key that can be shared freely, and a private key kept secret, like a lock that only you have the key to. When you initiate an SSH connection, the server sends a challenge encrypted with your public key. Only your private key can decrypt it, proving you are who you claim. This is called public key authentication, and it is much stronger than a simple password.
Once authenticated, all traffic between your computer and the server is encrypted, including keystrokes, file transfers, and even the colors and text that appear on your screen. This makes SSH essential for managing remote servers, routers, firewalls, and cloud instances, as it protects against password theft, data tampering, and session hijacking.
Full Technical Definition
SSH, defined in RFC 4251, is a protocol for secure remote login and other network services over an insecure network. It operates on a client-server model, typically using TCP port 22. The protocol has three major layers: the Transport Layer, the User Authentication Layer, and the Connection Layer.
The Transport Layer handles initial key exchange, server host key verification, encryption, and integrity protection. During key exchange, the client and server negotiate a symmetric encryption algorithm (such as AES or ChaCha20), a message authentication code (MAC) algorithm (like HMAC-SHA2), and a key exchange method (such as Diffie-Hellman or ECDH). The server presents its host key, which the client can verify against a known list to prevent man-in-the-middle attacks. A shared session key is derived, and all subsequent traffic is encrypted using the agreed symmetric cipher.
The User Authentication Layer runs over the encrypted transport. The client authenticates to the server using one or more methods: password authentication (with the password sent inside the encrypted tunnel), public key authentication, keyboard-interactive (which can challenge with multiple factors), or host-based authentication. In public key authentication, the client proves possession of the private key by signing a challenge sent by the server. The server checks the signature against the public key stored in the user's authorized_keys file.
The Connection Layer multiplexes multiple logical channels over the single encrypted connection. Channels can carry interactive shell sessions, remote command execution, file transfers (via SFTP or SCP), port forwarding, X11 forwarding, and TCP/IP tunnel connections. SSH also supports port forwarding, including local forwarding (forwarding a local port to a remote service), remote forwarding (making a remote port available locally), and dynamic forwarding (SOCKS proxy).
SSH uses cryptographic primitives including RSA, ECDSA, and Ed25519 for host keys, and public key algorithms for client authentication. Common implementations include OpenSSH (the de facto standard on Linux and macOS), PuTTY (Windows), and commercial solutions like Tectia. SSH is foundational for DevOps workflows, allowing secure automation with tools like Ansible, rsync over SSH, and Git operations via SSH protocol. It is also used for secure tunneling, replacing VPNs in some cases, and for accessing services behind NAT or firewalls through reverse tunnels.
Real-Life Example
Imagine you live in a large apartment building with a secure package delivery room. You want to send a confidential document to a neighbor on the 12th floor, but you cannot leave your apartment because you are working. You decide to use a secure messenger service that uses a sealed, tamper-proof tube carried by a trusted courier. You write your message, seal it in the tube with a special lock that only your neighbor has the key for, and give it to the courier. The courier takes the elevator, hands the tube to your neighbor, who unlocks it and reads the message. Nobody else can open the tube or read the message during transit.
In this analogy, you are the SSH client, your neighbor is the SSH server, the elevator is the network path, and the sealed tube is the encrypted SSH session. The special lock represents the public key cryptography used to authenticate and encrypt the session. The courier is the TCP connection over which SSH runs. Even if someone steals the tube, they cannot break the lock or read the document.
Now imagine the courier tries to impersonate your neighbor. If your neighbor had previously given you a unique seal that only their lock can match, you would immediately notice if the courier showed a different seal. This is how SSH host key verification works to prevent man-in-the-middle attacks.
If you want to send multiple documents or even have a conversation, the courier can make multiple trips through the same secure tube system, which mirrors how SSH multiplexes multiple channels over one encrypted connection. You could even ask the courier to bring back a medicine from the pharmacy on the first floor, similar to how SSH can forward ports to access other services. The entire system ensures that your interaction remains private, authenticated, and tamper-proof, just like SSH does for remote server administration.
Why This Term Matters
SSH is the backbone of secure remote administration for virtually every IT environment. Without it, administrators would have to physically sit at each server or use insecure protocols like Telnet, which sends passwords and data in plaintext. In modern cloud computing, where servers may be scattered across data centers worldwide, SSH is the standard method for accessing and managing Linux and Unix-based instances, network switches, and firewalls.
SSH enables secure file transfers via SFTP and SCP, replacing FTP which sends credentials in the clear. It also allows secure tunneling of other protocols, such as accessing a database behind a firewall without exposing it to the internet. This is crucial for security compliance standards like PCI-DSS and HIPAA, which require encrypted transmission of sensitive data.
For automation and configuration management, SSH is indispensable. Tools like Ansible, Puppet, and Chef use SSH to execute commands on remote hosts without installing agent software. Developers use SSH to push code to repositories on GitHub or GitLab, and to access production servers for debugging. Without SSH, many DevOps practices would be impossible or significantly less secure.
SSH also plays a role in identity and access management. The use of SSH keys instead of passwords reduces the risk of credential theft and brute-force attacks. Organizations can enforce key-based authentication, disable password logins, and even use SSH certificates for short-lived credentials, improving security posture. In regulated industries, SSH session logging and monitoring help satisfy audit requirements.
Any IT professional who manages servers, networks, or cloud infrastructure must understand SSH configuration, key management, and troubleshooting. A misconfigured SSH server can lead to security breaches, while proper use of SSH ensures safe, compliant remote access. Mastering SSH is not just a technical skill; it is a fundamental requirement for secure system administration.
How It Appears in Exam Questions
On certification exams, SSH questions appear in multiple forms. First, there are identification questions where you must recall port numbers and protocol names. For example, Which protocol runs on TCP port 22 and provides encrypted remote login? The answer is SSH. Other questions might ask, Which protocol is the secure replacement for Telnet?
Second, scenario-based questions test your understanding of when to use SSH versus other protocols. A typical A+ or Network+ question might describe a network administrator who needs to reconfigure a router remotely but must ensure the communication is encrypted. You would choose SSH over Telnet, HTTP, or FTP.
Third, configuration questions are common, especially in Linux+ and CCNA. A Linux+ question might provide a snippet of /etc/ssh/sshd_config and ask what effect a directive has, or ask you to identify the correct command to generate an RSA key pair. A CCNA question might present a configuration where SSH fails and ask you to identify the missing step, such as not generating RSA keys or not configuring a domain name.
Fourth, troubleshooting questions require you to diagnose why an SSH connection fails. Common causes include incorrect file permissions on the user's .ssh directory or authorized_keys file (it must not be group-writable), an SSH daemon not running, a firewall blocking port 22, or mismatched host key. A question might give the output of ssh -v and ask you to interpret the verbose messages to find the issue.
Fifth, security-focused questions test your knowledge of SSH best practices. For example, Why should you disable root login via SSH? Or, What is the advantage of using SSH keys over passwords? In Security+, you might see a question about using SSH tunnels to bypass firewalls or protect non-encrypted protocols like VNC.
Finally, some questions test the difference between SSH and related technologies, such as SSL/TLS or VPNs. For instance, An administrator needs to securely transfer files between two servers. Which protocol uses SSH for encryption? The answer is SFTP or SCP. These question types require clear understanding of SSH's role in the broader security landscape.
Practise SSH Questions
Test your understanding with exam-style practice questions.
Example Scenario
A small business uses a Linux web server hosted at a data center to run their online store. The IT manager, Maria, needs to update the server's configuration to fix a security issue. She cannot walk to the data center because it is in another city. Her only access to the server is over the internet.
Maria could use Telnet, which would send her login credentials in plain text across the internet. Anyone monitoring the network could capture her password and later break into the server. Instead, Maria opens an SSH client on her laptop and initiates an SSH connection to the server's IP address on port 22.
The server responds with its public host key. Maria has previously verified this key, so the connection continues. The two computers perform a secure key exchange, establishing an encrypted session. Maria then enters her username and password, which are sent through the encrypted tunnel. The server authenticates her and grants a remote shell.
Once connected, Maria types commands to edit the server's configuration files, restart services, and verify the fix. All of her keystrokes, the text that appears on her terminal, and any files she edits are transmitted securely. When she is done, she types exit to close the session.
Later, a junior administrator asks why they cannot use Telnet because it is simpler. Maria explains that SSH encrypts everything, while Telnet sends data in cleartext. She also shows how SSH can use key pairs so that she never needs to enter a password, which is more secure and convenient for automation. This scenario illustrates the everyday need for SSH in remote server management and why it is a non-negotiable tool for any IT professional.
Common Mistakes
Leaving SSH password authentication enabled on internet-facing servers
Passwords can be guessed or brute-forced, especially if users choose weak passwords. Enabling password authentication increases the attack surface and exposes the server to automated password-guessing attacks from bots.
Disable PasswordAuthentication in sshd_config and enforce key-based authentication only. Use strong passphrases on private keys and consider using SSH certificates for additional control.
Setting incorrect permissions on the .ssh directory or authorized_keys file
SSH is strict about permissions. If the .ssh directory is group-writable or the authorized_keys file has permissions looser than 600, SSH will ignore the file and deny key-based authentication for security reasons.
Set ~/.ssh directory permissions to 700 (rwx------) and ~/.ssh/authorized_keys permissions to 600 (rw-------). Ensure the user's home directory is not writable by group or others.
Assuming SSH is only for remote shell access
Many IT professionals overlook SSH's capabilities like port forwarding, X11 forwarding, and file transfers. This limits their productivity and security options. For example, they might expose a database port to the internet instead of using an SSH tunnel.
Learn about SSH's features: local and remote port forwarding (-L, -R), dynamic forwarding (-D as a SOCKS proxy), SCP and SFTP for file transfers, and SSH agent forwarding for chained connections.
Not verifying SSH host keys when first connecting
Blindly accepting a host key without verification allows a man-in-the-middle attack. An attacker could intercept the connection and capture credentials or data.
Always verify the server's host key fingerprint out-of-band (e.g., via a secure channel or provided by the data center). Use the ssh-keygen -lf command to display the fingerprint and compare it to the expected value.
Using the same SSH key pair for multiple servers without passphrase protection
If a private key is compromised, every server that accepts the corresponding public key becomes vulnerable. Without a strong passphrase, anyone who gains access to the private key file can use it immediately.
Use different key pairs for different security zones (e.g., one for production, one for development). Always protect private keys with a strong passphrase. Consider using an SSH agent to avoid typing the passphrase repeatedly.
Exam Trap — Don't Get Fooled
{"trap":"In a question that asks for the default port of SSH, the exam might include an option for port 22 (correct) and also trap options like port 23 (Telnet) or port 443 (HTTPS). A deeper trap: a question might state that SSH uses TCP port 22 by default, but the answer choice says \"UDP port 22\", learners might not notice the protocol difference.","why_learners_choose_it":"Learners often memorize port 22 without noting that SSH runs over TCP, not UDP.
They may also confuse SSH with SSL/TLS, which uses port 443, or with Telnet on port 23.","how_to_avoid_it":"Memorize that SSH uses TCP port 22 exclusively. In questions, read the full answer choice carefully, including protocol (TCP vs.
UDP). Also remember that while SSH can be configured to use a different port, the default is TCP 22. Practice with port and protocol tables during study."
Step-by-Step Breakdown
Initiate TCP connection on port 22
The SSH client (ssh command) attempts to establish a TCP connection to the server's IP address on port 22. If the port is open, the TCP three-way handshake completes. If blocked by a firewall or the SSH daemon is not running, the connection fails immediately with a 'Connection refused' or 'Connection timed out' error.
Server presents host key and performs key exchange
The SSH server sends its public host key to the client. The client checks if this key matches a known host key stored in ~/.ssh/known_hosts. If unknown, the client displays the fingerprint and asks for confirmation. If the key has changed, a warning is shown. Then both sides perform a Diffie-Hellman key exchange to derive a symmetric session key.
Encrypted tunnel established
Using the negotiated symmetric encryption algorithm (e.g., AES-256) and the session key, all subsequent communication is encrypted. The client and server now have a secure, tamper-proof channel. This prevents eavesdropping and tampering from that point forward.
User authentication occurs
The client authenticates to the server using one of the configured methods. The most common are password authentication (password sent encrypted) or public key authentication (client proves possession of private key). The server checks the credentials against local user accounts or authorized keys. If authentication fails, the SSH daemon logs the attempt and may enforce rate limiting.
Session is opened and user gets shell or executes commands
After successful authentication, the SSH server creates a new session for the user. By default, it starts a shell (like bash) on the server. The client can now send keystrokes and receive output, all encrypted. Alternatively, the client can specify a command to run non-interactively (e.g., ssh user@host 'ls -l'). The session ends when the user types 'exit' or the command finishes.
Session termination
When the user closes the shell or the command completes, the SSH session is terminated. The underlying TCP connection is closed. The server may log the session start and end times. If the connection drops unexpectedly, the SSH daemon cleans up any remaining processes in the session to prevent orphaned processes.
Practical Mini-Lesson
To use SSH effectively in the real world, start by generating a key pair with ssh-keygen. The default algorithm is RSA, but for better security, use Ed25519 with ssh-keygen -t ed25519. This produces a key pair: a private key (id_ed25519) that must be kept secret and a public key (id_ed25519.pub) that can be copied to servers.
Copy the public key to a remote server using ssh-copy-id user@server. This adds the public key to the server's ~/.ssh/authorized_keys file. Ensure the permissions are correct: the .ssh directory must be 700, and the authorized_keys file must be 600. If permissions are wrong, SSH will silently ignore the key file and fall back to password authentication, or fail if passwords are disabled.
Configure the SSH daemon on the server by editing /etc/ssh/sshd_config. Common hardening steps include setting PermitRootLogin prohibit-password (or no), disabling PasswordAuthentication yes to no, enforcing PubkeyAuthentication yes, and changing the listening port from 22 to a non-standard port to reduce automated attacks. After changes, restart the service with systemctl restart sshd.
For day-to-day use, an SSH config file (~/.ssh/config) saves time. You can define hosts with aliases, specify usernames, keys, and custom ports. For example, Host webserver, HostName 192.168.1.100, User admin, IdentityFile ~/.ssh/web_key, Port 2222. Then you simply type ssh webserver.
Troubleshooting is a critical skill. Use ssh -v (or -vv or -vvv) for verbose output to see exactly where the connection fails. Common issues include firewall blocking port 22, SSH daemon not running (check with systemctl status sshd), incorrect key permissions, or the server not having the client's public key in authorized_keys. Also check logs on the server via journalctl -u sshd or /var/log/auth.log for authentication failures.
SSH forwarding is a powerful feature for accessing internal services securely. For example, to access a database on a server that only listens on localhost, use ssh -L 3306:localhost:3306 user@server. This tunnels your local port 3306 to the server's localhost:3306. You can then use a database client on your machine to connect securely. Reverse forwarding (ssh -R) is useful for exposing a local service to a remote network.
Professionals often use SSH agent forwarding to connect through a jump box (bastion host) without copying keys. Use ssh -A to forward the agent. However, be cautious because agent forwarding can be abused if the intermediate host is compromised. Alternative solutions include SSH proxy jump with ssh -J which is more secure.
In cloud environments like AWS, SSH keys are used to access EC2 instances. You download the private key (.pem file) and use it with ssh -i key.pem ec2-user@public-ip. The first connection may ask to verify the host key, but AWS provides host key fingerprints in the instance console output for verification. Always set the .pem file permissions to 400 (or 600) because SSH will refuse to use a private key that is accessible by others.
Memory Tip
SSH = Secure Shell, port 22, encrypted tunnel for remote commands. Remember 'Secure Shell' not 'sh' which is the shell itself.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
200-301Cisco CCNA →220-1101CompTIA A+ Core 1 →N10-009CompTIA Network+ →220-1102CompTIA A+ Core 2 →XK0-006CompTIA Linux+ →SC-900SC-900 →PCAGoogle PCA →CDLGoogle CDL →ISC2 CCISC2 CC →Legacy Exam Context
Older materials may mention these exam versions, but learners should use the current objectives for their target exam.
N10-008N10-009(current version)SY0-601SY0-701(current version)XK0-005XK0-006(current version)Related Glossary Terms
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
AAA (Authentication, Authorization, and Accounting) is a security framework that controls who can access a network, what they are allowed to do, and tracks what they did.
Frequently Asked Questions
What port does SSH use?
SSH uses TCP port 22 by default. You can configure it to use a different port in the SSH daemon configuration file (sshd_config) with the Port directive, but port 22 is the standard.
Is SSH the same as SSL?
No, SSH and SSL are different protocols. SSH is designed for secure remote login and command execution, while SSL/TLS is used to encrypt web traffic, email, and other application protocols. They use different ports (22 vs 443) and different authentication methods.
Can SSH be used for file transfer?
Yes, SSH includes file transfer capabilities through SFTP (SSH File Transfer Protocol) and SCP (Secure Copy). Both provide encrypted file transfer using the same secure channel as the SSH connection.
Why is SSH more secure than Telnet?
Telnet sends all data, including usernames and passwords, in plaintext over the network. Anyone with network access can capture this information. SSH encrypts the entire session, including authentication, making it unreadable to eavesdroppers.
What are SSH keys and how do they work?
SSH keys are a pair of cryptographic keys: a private key kept secret on your local machine and a public key placed on the server. When you connect, the server challenges you to prove possession of the private key. This provides strong authentication without sending a password.
What does 'Connection refused' mean when using SSH?
This error typically means the SSH daemon (sshd) is not running on the target server, or a firewall is actively dropping packets on port 22. Check that the SSH service is started and that the server's firewall allows inbound TCP traffic on port 22.
How do I disable root login over SSH?
Edit the /etc/ssh/sshd_config file and set 'PermitRootLogin no' or 'PermitRootLogin prohibit-password'. Then restart the SSH service with 'systemctl restart sshd'. This prevents direct root access via SSH and encourages using sudo.
Summary
SSH (Secure Shell) is a fundamental protocol for secure remote administration, file transfer, and tunneling. It provides encryption, authentication, and integrity protection for communications over insecure networks like the internet. SSH has replaced older insecure protocols such as Telnet, rlogin, and FTP, and is a standard tool for managing Linux/Unix servers, network devices, and cloud instances.
For IT certification candidates, SSH is a recurring topic across many exams from CompTIA A+ and Network+ to Linux+, Security+, and CCNA. You need to know its default port (TCP 22), how to generate and use keys, configure the SSH daemon, and troubleshoot common issues. Understanding the difference between SSH and similar technologies like Telnet, SSL, and VPNs is also important.
In practice, SSH is more than just a remote shell. Its port forwarding capabilities allow secure access to internal services, while its key-based authentication improves security and enables automation. Mastering SSH configuration, key management, and troubleshooting will serve you well both in exams and in your IT career. Always prioritize security: disable password authentication, use strong key algorithms, verify host keys, and protect private keys with passphrases. SSH is not just a tool, it is a core competency for any serious IT professional.