SSH (Secure Shell) – Secure Remote Access

1. What Is SSH?

SSH (Secure Shell) is a cryptographic network protocol that provides secure remote login, command execution, file transfer, and port forwarding over an unsecured network. Defined in RFC 4251–4254, SSH replaced insecure legacy protocols — primarily Telnet (port 23) — and operates at OSI Layer 7 (Application Layer) over TCP port 22.

SSH delivers three fundamental security properties for every session:

  • Confidentiality: All data (including passwords and commands) is encrypted — an attacker capturing packets sees only ciphertext
  • Integrity: Message Authentication Codes (MACs) detect any tampering with data in transit
  • Authentication: Both the server and client are verified before any data is exchanged
  SSH Client                                SSH Server
  (PuTTY, OpenSSH, SecureCRT)              (Cisco IOS, Linux sshd)
        |                                         |
        |-- TCP SYN -> port 22 ------------------>|  Step 1: TCP connection
        |<-- TCP SYN-ACK -------------------------|
        |                                         |
        |<--- SSH Version & Algorithm Exchange ---->|  Step 2: Protocol negotiation
        |                                         |
        |<--- Key Exchange (Diffie-Hellman) ------->|  Step 3: Session key established
        |                                         |
        |-- Authentication (password/key) ------->|  Step 4: Client authenticates
        |                                         |
        |====== Encrypted Session Begins =========|  Step 5: All traffic encrypted

Related pages: Telnet | FTP (File Transfer Protocol) | Firewalls | ACL Overview | Standard & Extended ACLs | Common Network Ports | OSI Model | SSH & Telnet Security | Step-by-Step: SSH Configuration

2. SSH Versions

VersionStatusSecurityAction
SSH-1 Obsolete — do not use Multiple known vulnerabilities including man-in-the-middle attacks and session hijacking Disable explicitly: ip ssh version 2 on Cisco; Protocol 2 in sshd_config on Linux
SSH-2 Current standard — always use Modern, secure architecture with separate transport, authentication, and connection layers; supports AES, ECDSA, Ed25519 Enable and enforce in all production environments

3. SSH Components

ComponentDescriptionExamples
SSH ClientInitiates the SSH connection to a remote hostssh (OpenSSH), PuTTY, SecureCRT, MobaXterm, Termius
SSH ServerListens on TCP port 22 and accepts incoming SSH connectionsOpenSSH sshd (Linux/Unix), Cisco IOS SSH server, Windows OpenSSH
Host KeysThe server's public/private key pair used to prove the server's identity to clientsRSA, ECDSA, or Ed25519 key pairs generated on the server
User KeysClient's public/private key pair used for passwordless authentication~/.ssh/id_rsa, ~/.ssh/id_ed25519 (generated with ssh-keygen)

4. SSH Authentication Methods

MethodHow It WorksSecurityWhen to Use
Password User enters username and password; server validates against its user database Medium — password is encrypted in transit but vulnerable to brute-force if weak Simple setups; always combine with rate limiting and brute-force protection
Public Key Client proves possession of the private key corresponding to the public key installed on the server in ~/.ssh/authorized_keys High — private key never leaves the client; immune to password brute-force Preferred method for all production servers and automation
Certificate SSH CA signs user/host certificates; server trusts the CA rather than individual keys Very High — scales to thousands of servers without deploying individual public keys Large enterprise deployments with centralised SSH management — see AAA Overview

5. SSH Key Management

Step 1 — Generate a Key Pair (Linux/macOS)

ssh-keygen -t ed25519 -C "[email protected]"    # Modern, recommended
ssh-keygen -t rsa -b 4096                        # RSA 4096-bit (also acceptable)

This creates two files:

  • ~/.ssh/id_ed25519 — Private key — never share or copy to other systems
  • ~/.ssh/id_ed25519.pub — Public key — install this on remote servers

Step 2 — Deploy Public Key to a Remote Server

ssh-copy-id [email protected]

This appends your public key to ~/.ssh/authorized_keys on the remote server. After this, you can log in without a password.

Step 3 — Protect the Private Key with a Passphrase

Always set a passphrase when generating keys. The passphrase encrypts the private key file on disk — even if an attacker steals the file, they cannot use it without the passphrase.

Using SSH Agent for Convenience

eval $(ssh-agent)           # Start the agent
ssh-add ~/.ssh/id_ed25519   # Load your key (enter passphrase once)

The agent holds the decrypted key in memory for the session, so you only enter the passphrase once per login session.

6. Configuring SSH on Cisco IOS

SSH is the required secure management protocol for all Cisco devices. Telnet must be disabled after SSH is configured. See also Console & VTY Line Configuration.

Full SSH Configuration Example

! Step 1: Set a hostname (required for RSA key generation)
Router(config)# hostname Router1

! Step 2: Set a domain name (required for RSA key generation)
Router1(config)# ip domain-name example.com

! Step 3: Generate RSA key pair (minimum 1024 bits; 2048 recommended)
Router1(config)# crypto key generate rsa modulus 2048

! Step 4: Enforce SSH version 2 only (disables insecure SSH-1)
Router1(config)# ip ssh version 2

! Step 5: Set SSH timeout and authentication retry limits
Router1(config)# ip ssh time-out 60
Router1(config)# ip ssh authentication-retries 3

! Step 6: Create a local user account
Router1(config)# username admin privilege 15 secret StrongP@ssword2025

! Step 7: Configure VTY lines to use SSH only
Router1(config)# line vty 0 4
Router1(config-line)# login local
Router1(config-line)# transport input ssh

! Step 8: Verify
Router1# show ip ssh
Router1# show ssh

Restricting SSH Access with an ACL

Router1(config)# access-list 10 permit 192.168.1.0 0.0.0.255
Router1(config)# line vty 0 4
Router1(config-line)# access-class 10 in

Only hosts in 192.168.1.0/24 can reach the VTY lines via SSH. See Applying ACLs and Wildcard Masks for more detail.

7. SSH Client Usage

Basic Connection

ssh [email protected]           # Connect as user "admin"
ssh -p 2222 [email protected]  # Connect to non-default port 2222
ssh -v [email protected]       # Verbose mode for troubleshooting

Using an SSH Config File for Shortcuts

Create ~/.ssh/config to define host aliases:

Host router1
    HostName 192.168.1.1
    User admin
    Port 22
    IdentityFile ~/.ssh/id_ed25519

Then connect simply with: ssh router1

8. SSH Tunneling and Port Forwarding

SSH can forward TCP ports through an encrypted tunnel — useful for securing unencrypted protocols or bypassing firewall restrictions. For full network-layer VPN tunneling, see IPsec VPN and GRE Tunnels.

TypeCommand ExampleUse Case
Local Forwarding ssh -L 8080:localhost:80 admin@server Access a web server on the remote network via localhost:8080 on your machine
Remote Forwarding ssh -R 8080:localhost:80 admin@server Allow remote users to access a service on your local machine
Dynamic Forwarding ssh -D 1080 admin@server Create a SOCKS5 proxy — route all browser traffic through the SSH tunnel

9. Security Best Practices

PracticeImplementationBenefit
Always use SSH-2ip ssh version 2 (Cisco) | Protocol 2 (sshd_config)Eliminates SSH-1 vulnerabilities
Disable password auth, use keysPasswordAuthentication no in sshd_configEliminates brute-force password attacks entirely
Disable root loginPermitRootLogin no in sshd_configPrevents direct root compromise
Restrict access with ACL/firewallAllow TCP 22 only from management networks — see ACL Overview and FirewallsReduces attack surface dramatically
Change default portPort 2222 in sshd_configReduces automated scanning noise (security through obscurity — not a primary control)
Set session timeoutsip ssh time-out 60 | ClientAliveInterval 300Terminates abandoned sessions
Use strong ciphersConfigure AES-256-GCM, ChaCha20; disable 3DES, RC4Ensures only modern encryption algorithms are negotiated

10. SSH vs Telnet — Summary Comparison

FeatureSSH (Secure Shell)Telnet
EncryptionYes — all session data is encryptedNo — all data including passwords in plaintext
PortTCP 22 (default)TCP 23
AuthenticationPassword, public key, certificatePassword only (in plaintext)
IntegrityYes — MACs detect tamperingNo
Use for ManagementYes — required for all production devicesNo — testing and legacy troubleshooting only
File TransferYes — SCP and SFTP over SSHNo
Port ForwardingYes — local, remote, dynamicNo
RFC / StandardRFC 4251–4254 (SSH-2)RFC 854

11. Troubleshooting SSH Connections

SymptomLikely CauseFix
Connection refused (port 22)SSH server not running, firewall blocking TCP 22, wrong IP/hostnameVerify show ip ssh (Cisco) or systemctl status sshd (Linux); check firewall rules and ACLs
Authentication failed (password)Wrong password, account locked, SSH server rejecting passwordsVerify credentials, check PasswordAuthentication yes in sshd_config
Permission denied (publickey)Public key not in authorized_keys, wrong file permissions, wrong keyRun ssh-copy-id; verify ~/.ssh/authorized_keys permissions (600) and ~/.ssh (700)
Host key verification failedServer's host key changed (or MITM attack)If legitimate: remove old entry from ~/.ssh/known_hosts; if suspicious: investigate before proceeding
SSH hangs after connectionRouting problem, firewall allowing SYN but dropping establishedCheck return path routing; use ssh -v for detailed negotiation trace

Debugging SSH with Verbose Mode

ssh -v [email protected]    # Basic verbose — shows handshake steps
ssh -vv [email protected]   # More detail
ssh -vvv [email protected]  # Maximum verbosity — shows every packet

12. Advanced SSH Features

  • Multiplexing: Reuse a single SSH connection for multiple sessions — ControlMaster auto in ssh config significantly speeds up repeated connections
  • Agent forwarding: Use your local SSH keys on a remote server to connect to further hosts — ssh -A admin@jump-host
  • Jump hosts (ProxyJump): Reach hosts behind a bastion server — ssh -J [email protected] admin@internal-host
  • SSHFS: Mount a remote filesystem securely over SSH — sshfs admin@server:/var/www /mnt/remote

SSH – Secure Remote Access Quiz

1. What does SSH stand for, and what is its primary purpose?

Correct answer is B. SSH stands for Secure Shell. It provides encrypted remote login, command execution, file transfer (SCP/SFTP), and port forwarding over untrusted networks. It replaced Telnet and other plaintext protocols as the standard for secure network device management.

2. Which SSH version is required for all secure deployments, and why?

Correct answer is C. SSH-2 is the current secure standard, addressing multiple known vulnerabilities in SSH-1 including man-in-the-middle attacks, session hijacking, and weak MAC algorithms. Always enforce SSH-2 with ip ssh version 2 on Cisco devices and Protocol 2 in sshd_config on Linux.

3. Which TCP port does SSH use by default?

Correct answer is A. SSH listens on TCP port 22 by default. TCP port 23 is Telnet. TCP port 21 is FTP control. TCP port 80 is HTTP. Ensure TCP port 22 is permitted through any firewall between SSH clients and the managed devices.

4. Which SSH authentication methods are commonly supported?

Correct answer is D. SSH supports three primary authentication methods: password (simplest, vulnerable to brute-force), public key (preferred — client proves ownership of private key without transmitting it), and certificate (CA-signed keys, scales to large deployments). Public key authentication is recommended for all production systems.

5. What is the correct command to generate a 4096-bit RSA SSH key pair on Linux?

Correct answer is B. ssh-keygen -t rsa -b 4096 generates a 4096-bit RSA key pair. The -t flag specifies the key type and -b specifies the bit length. For modern deployments, Ed25519 (ssh-keygen -t ed25519) is recommended as it provides equivalent security with much shorter keys and faster operations.

6. Which command copies your SSH public key to a remote server for passwordless authentication?

Correct answer is A. ssh-copy-id user@server appends your public key to the server's ~/.ssh/authorized_keys file. After running this, you can SSH to that server without entering a password. The alternative is manually copying the contents of ~/.ssh/id_*.pub into the server's authorized_keys file.

7. What is the major security advantage of SSH over Telnet?

Correct answer is C. Telnet transmits everything — including usernames, passwords, and all commands — in plaintext. Anyone with access to the network path (a packet sniffer, a compromised switch, a MITM position) can read the entire session. SSH encrypts all traffic from the moment the session is established. This is the reason Telnet must never be used for managing production devices.

8. What is the correct Cisco IOS command to enforce SSH version 2 only?

Correct answer is D. ip ssh version 2 is the Cisco IOS global configuration command that restricts SSH to version 2 only, disabling the insecure SSH-1. This should always be configured alongside crypto key generate rsa (minimum 1024-bit), a domain name, hostname, and VTY lines set to transport input ssh.

9. What does ssh -v user@host do?

Correct answer is A. The -v flag enables verbose mode, printing detailed debug output of the entire SSH connection process — protocol negotiation, key exchange, authentication attempts, and any errors. Use -vv or -vvv for progressively more detail. This is the primary troubleshooting tool when SSH connections fail unexpectedly.

10. Which of the following is NOT a recommended SSH security best practice?

Correct answer is B. SSH-1 is fundamentally insecure and must be disabled — not kept as a fallback. Any device that genuinely cannot support SSH-2 should be isolated, upgraded, or replaced. "Backward compatibility" with an insecure protocol is never an acceptable reason to weaken security on a production device. Enforce SSH-2 exclusively with ip ssh version 2 on Cisco.

← Back to Home