Back to Learning
CCNA · 200-301Beginner

SSH Remote Access: Enabling It Properly

SSH is refused and generating a key fails with an error of its own. Build the prerequisites in the right order yourself, live, right below.

Interactive simSecuritySSHDevice Hardening

Symptom

Telnet works, SSH is refused, and generating a key returns an error. Build the four prerequisites SSH actually needs, in the right order, then close Telnet off.

Your mission

Prove the cause, then fix it

Format

Guided CLI investigation

SSH Remote Access Hardening

Investigate before you configure.

Use the CLI evidence to isolate the fault, make the smallest safe correction, then verify the network state changed.

Observe the symptom and link state.

Diagnose by comparing the protocol evidence.

Verify the expected device state and confirm the original symptom is resolved.

Console access: R1

This workspace stacks for portrait phones. Rotate to landscape for the full split-screen console.

Need a hint?

Reveal the root cause when you're ready.

Try the investigation first, then use this as your escape hatch, not a dead end.

Locked

Sign up with your email to open SSH Remote Access: Enabling It Properly, free. You get the root cause and the full step-by-step fix.

No spam. The fix lands in your inbox too. Signing up includes 4 guided labs free, tracked against your email. After that, the Learning Pass unlocks every remaining lab.

Lab debrief

Turn the session into a repeatable troubleshooting pattern.

Use this reference after your attempt: first explain the symptom, then verify the evidence, then confirm the repair.

The problem

A router is reachable over Telnet but every SSH attempt is refused. show ip ssh reports SSH disabled, and the obvious first move, generating an RSA key pair, fails with an error of its own.

What you'll practice

  • Read SSH server state and version from the device
  • Understand why an RSA key pair needs a fully qualified domain name first
  • Generate keys of a size SSH version 2 will accept
  • Configure local authentication for the vty lines
  • Restrict vty transport to SSH and confirm Telnet is closed

The topology

A single router with a management interface. The topology is deliberately minimal so the evidence is the device's own SSH and key state, not a reachability problem.

Commands to run yourself

The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.

Read SSH server state
show ip ssh
Check for an existing key pair
show crypto key mypubkey rsa
Read the vty line configuration
show running-config | section line vty

Topology diagram

Frequently asked

Why does crypto key generate rsa fail before anything else is configured?

The key pair is named after the device's fully qualified domain name, so IOS refuses to generate one until both a hostname and an ip domain-name are set. Set the domain name first and the same command succeeds.

Why 2048 bits rather than the default?

SSH version 2 requires a modulus of at least 768 bits, and the device itself reports a minimum expected Diffie-Hellman key size of 2048. Generating at 2048 avoids being quietly limited to version 1.99.

Is transport input ssh enough on its own?

It closes Telnet, which matters, but a vty line still needs a way to authenticate. Without login local plus a username, restricting the transport can leave you locked out rather than secured.

Ready to run this lab yourself?

No setup, no image sourcing. Book a session or ask for a live demo.