Imagine you're a network engineer sitting at your desk, trying to SSH into a remote router to fix a critical routing issue. You type the command, wait... and get 'Connection refused'. Your heart sinks. This is a classic scenario on the CCNA 200-301 exam (Objective 4.7) and in real life. 'SSH Connection Refused' is one of the most common and frustrating connectivity failures. Mastering its troubleshooting is essential for any network professional because SSH is the de facto standard for secure remote device management. This chapter will give you a systematic, exam-focused approach to diagnosing and resolving this error.
Jump to a section
A simple way to picture Troubleshoot: SSH Connection Refused
Suppose you are using SSH to try to gain entry to an exclusive VIP club. Your device (client) wants to get in, but there's a strict bouncer (the SSH server process on the router/switch) at the door. The bouncer checks a list of approved guests (the local user database or AAA server). For you to enter, several things must be in order. First, the club must be open (the SSH server must be enabled globally with 'ip ssh version 2' and a hostname/domain configured). If the club is closed, you get 'Connection refused' immediately. Second, you must be on the guest list (the username must exist locally or on an AAA server, and you must provide the correct password). If your name isn't on the list, the bouncer says 'Access denied' after you try to enter. Third, the bouncer must be at the right door (the VTY lines must be configured to accept SSH connections, using 'transport input ssh'). If the bouncer is at a different door (e.g., only Telnet is allowed), you'll get 'Connection refused' because the SSH daemon isn't listening on that line. Fourth, there must be enough room in the club (the number of allowed simultaneous SSH sessions, 'ip ssh maxstartups' and VTY line count). If the club is full, you might get a timeout or a different error. Fifth, the bouncer must be able to see you (IP connectivity and ACLs on the VTY lines). If there's a firewall or ACL blocking your IP, the bouncer never even sees you, and you get a timeout, not a refusal. The 'Connection refused' message specifically means the bouncer is at the door, saw you, but actively rejected your entry attempt — usually because the SSH service is not running on that port, or the VTY lines are not configured for SSH, or the server is overwhelmed (but that's rare). Understanding this analogy helps you map each potential failure point to a specific IOS configuration or connectivity issue.
What is SSH Connection Refused?
When you attempt to SSH to a Cisco device and receive 'Connection refused', it means the remote device actively rejected the TCP connection attempt to port 22. This is different from a timeout, where the client never gets a response. The refusal indicates that the destination host is reachable (ICMP echo may work), but no service is listening on TCP port 22, or an ACL is explicitly blocking the connection. In the CCNA exam, this error is a common distractor in troubleshooting scenarios.
Why Does It Happen?
There are four primary causes for SSH Connection Refused on a Cisco IOS device:
SSH Server Not Enabled: The device has not been configured to run an SSH server. This requires:
- A hostname (not the default 'Router' or 'Switch')
- A domain name (via ip domain-name)
- RSA key pair generated (via crypto key generate rsa)
- SSH version 2 enabled (via ip ssh version 2)
VTY Lines Not Configured for SSH: Even if the SSH server is running, the VTY lines (virtual terminal lines used for remote access) must be configured to accept SSH connections. The command transport input ssh on the VTY lines is mandatory. If the VTY lines only allow Telnet (transport input telnet) or nothing (transport input none), SSH connections will be refused.
ACL Blocking SSH: An access control list (ACL) applied to the VTY lines (via access-class) can permit or deny specific source IP addresses. If the ACL denies the client's IP, the connection is refused.
Port Mismatch or Service Disabled: The SSH service might be configured to listen on a non-default port (via ip ssh port), or the service could be administratively shut down (though rare).
Step-by-Step Mechanism at Packet Level
When a client initiates an SSH connection:
The client sends a TCP SYN packet to the destination IP address on port 22.
If the destination receives the SYN and has a process listening on port 22, it responds with a SYN-ACK. If not, it sends an RST (reset) packet, causing the 'Connection refused' error on the client.
The exact packet-level behavior when an ACL denies a VTY connection attempt varies by IOS version and platform. In some cases the router sends a TCP RST, producing 'Connection refused'; in others the packet is silently dropped, producing a timeout instead. Because this behavior isn't universally consistent, don't assume a VTY ACL denial always produces one specific symptom — verify against the actual device and IOS version in a real troubleshooting scenario rather than relying on a single fixed rule.
Key Configuration and Verification Commands
To verify SSH configuration:
show ip sshExample output:
SSH Enabled - version 2.0
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie-Hellman key size : 1024 bits
IOS Keys in SECSH format(ssh-rsa, SSH host key): ...If SSH is not enabled, the output will be minimal or show 'SSH Disabled'.
To check VTY line configuration:
show line vty 0 4Look for the 'Transport' field. It should include 'ssh'.
To check ACL applied to VTY:
show running-config | section line vtyLook for access-class statements.
How SSH Interacts with Related Protocols
SSH relies on TCP for reliable transport. If there is a routing issue, SSH may time out rather than refuse. SSH also depends on AAA (if configured) for authentication. If AAA is misconfigured, you might get 'Authentication failed' after connection, not 'Connection refused'. DNS can also affect SSH if the device tries to resolve the client's hostname, but that usually causes delays, not refusal.
Common Exam Traps
The candidate forgets to configure ip domain-name and crypto key generate rsa. The router will not start SSH without these.
The candidate confuses transport input ssh with transport output ssh. Input is for incoming connections (SSH to the device), output is for outgoing connections (SSH from the device).
The candidate thinks ACLs on VTY lines always cause timeout. They can cause refusal if the ACL is explicitly denying the source.
The candidate overlooks the need for a hostname that is not the default. The default hostname 'Router' or 'Switch' will cause SSH to fail because the RSA key generation uses the hostname and domain.
IOS CLI Verification Commands with Real Example Output
R1# show ip ssh
SSH Enabled - version 2.0
Authentication timeout: 120 secs; Authentication retries: 3R1# show running-config | include ip ssh
ip ssh version 2R1# show running-config | section line vty
line vty 0 4
password cisco
login local
transport input sshIf the transport input is missing or set to 'telnet', SSH will be refused.
Check SSH Server Status
Use `show ip ssh` on the target device. If the output shows 'SSH Disabled' or no version, SSH is not running. This is the most common cause. To enable SSH, ensure the device has a hostname (not default), a domain name configured with `ip domain-name`, and an RSA key pair generated with `crypto key generate rsa`. Then enable SSH version 2 with `ip ssh version 2`. Verify with `show ip ssh` again. If the output shows version 2.0, the server is running.
Verify VTY Line Transport
Check the VTY line configuration with `show running-config | section line vty`. Look for `transport input ssh`. If it says `transport input telnet` or `transport input none`, change it to `transport input ssh`. Also ensure that login authentication is configured (e.g., `login local` or `login authentication default`). If the VTY lines are misconfigured, SSH connections will be refused even if the SSH server is running.
Check ACL on VTY Lines
If an `access-class` is applied to the VTY lines, it can block SSH. Use `show running-config | include access-class` to see if any ACL is applied. Then examine the ACL with `show access-lists <acl-number>`. If the ACL denies your source IP, you will get a 'Connection refused'. Modify the ACL to permit your IP. Remember that ACLs on VTY lines filter after the TCP handshake, so the refusal is explicit.
Verify TCP Port 22 Listening
On the target device, use `show tcp brief` to see if any process is listening on port 22. Look for an entry with '22' in the local port column and 'LISTEN' state. If no such entry exists, the SSH server is not listening. This could be due to SSH not being enabled or a port mismatch (if `ip ssh port` is configured to a different port). Ensure the client is connecting to the correct port.
Check Authentication Configuration
Although 'Connection refused' is not an authentication error, misconfigured authentication can sometimes cause the SSH server to reject connections prematurely. Verify that local usernames exist with `show running-config | include username`. If using AAA, check `show aaa servers` and `show running-config | section aaa`. Ensure the login method on VTY lines matches the configured authentication (e.g., `login local` requires local users).
Test with Telnet to Port 22
From the client, use telnet to the device's IP on port 22: `telnet <ip> 22`. If you get 'Connection refused', the device is actively rejecting the connection. If you get a timeout, the device may be unreachable. This test isolates whether the issue is at the TCP level or higher. If telnet to port 22 gives a different result than SSH, the problem might be with the SSH client itself.
In enterprise networks, SSH is the primary method for managing network devices. A 'Connection refused' error can halt critical changes and cause outages. Consider a scenario where a junior network engineer tries to SSH to a core switch to add a new VLAN. The engineer gets 'Connection refused'. They panic and call the senior engineer. The senior engineer logs into the console, runs show ip ssh, and sees that SSH is disabled because the switch was recently replaced and the new one has the default hostname 'Switch'. The senior engineer configures a hostname, domain name, and generates RSA keys. Problem solved. Another common scenario: a network operations center (NOC) has multiple engineers accessing devices from a management subnet. An ACL is applied to VTY lines that permits only the management subnet. If a new engineer is assigned a different IP (e.g., from a VPN pool), they get 'Connection refused'. The ACL needs to be updated. In production, it's critical to have a standard SSH configuration template that includes hostname, domain, RSA key generation, and VTY transport input ssh. Also, use AAA for centralized authentication and authorization. When misconfigured, SSH issues can lead to security vulnerabilities (e.g., allowing Telnet) or lockouts. Always keep a console connection as a backup. Performance-wise, SSH uses encryption, which can be CPU-intensive on older devices. Use ip ssh version 2 for better security and performance. The ip ssh maxstartups command limits concurrent SSH sessions to prevent resource exhaustion. In large networks, SSH to a device can be slow if DNS is misconfigured, causing the device to try to reverse-lookup the client's IP. Disable DNS lookup with no ip domain-lookup on the VTY lines or globally to speed up connections.
The CCNA 200-301 exam tests SSH troubleshooting under Objective 4.7. Expect scenario-based questions where you must identify why an SSH connection is refused. The most common wrong answers are: 1. 'The username is incorrect.' — This causes 'Authentication failed' after connection, not 'Connection refused'. 2. 'The password is incorrect.' — Same as above. 3. 'The device is unreachable.' — This causes a timeout, not a refusal. 4. 'SSH version mismatch.' — This causes a negotiation failure, often resulting in 'Connection closed' or 'No matching cipher', not 'Connection refused'. The correct answers typically involve SSH not being enabled, VTY lines not configured for SSH, or an ACL blocking the connection.
Specific values to remember:
SSH uses TCP port 22.
The command to enable SSH version 2 is ip ssh version 2.
The command to set VTY transport is transport input ssh.
The command to generate RSA keys is crypto key generate rsa.
Default SSH timeout is 120 seconds, retries 3.
On the exam, you might be shown a partial configuration and asked what is missing. Look for missing hostname, ip domain-name, crypto key generate rsa, or transport input ssh.
Decision rule: If the error is 'Connection refused', focus on the server-side configuration (SSH enabled, VTY lines, ACLs). If the error is 'Timeout', focus on network connectivity (routing, firewalls). If the error is 'Authentication failed', focus on usernames/passwords or AAA.
Elimination strategy: When given multiple choices, eliminate any that mention authentication, passwords, or network reachability for 'Connection refused'. That leaves SSH server and VTY configuration issues.
SSH Connection Refused means the remote device actively rejected the TCP connection to port 22.
Common causes: SSH not enabled (missing hostname, domain, RSA keys), VTY lines not configured for SSH (transport input ssh), or ACL blocking the source.
Use 'show ip ssh' to verify SSH is enabled and 'show running-config | section line vty' to check transport input.
SSH uses TCP port 22; 'ip ssh version 2' enables modern SSH.
Default SSH authentication timeout is 120 seconds, with 3 retries.
ACLs on VTY lines (access-class) can cause 'Connection refused' if the source is denied.
Distinguish from 'timeout' (network issue) and 'authentication failed' (credentials issue).
These come up on the exam all the time. Here's how to tell them apart.
SSH Connection Refused
Active rejection with TCP RST
Indicates server is reachable but not listening
Causes: SSH disabled, VTY misconfig, ACL deny
Client sees immediate error
Troubleshoot server-side config
SSH Timeout
No response from server
Indicates network connectivity issue
Causes: routing, firewall, ACL on interface
Client waits for timeout
Troubleshoot network path
Mistake
SSH Connection Refused means the username or password is wrong.
Correct
Username/password errors cause 'Authentication failed' after a successful TCP connection. 'Connection Refused' occurs before authentication, at the TCP level.
Candidates often confuse connection establishment with authentication.
Mistake
If SSH is enabled, it automatically works on all VTY lines.
Correct
The VTY lines must be explicitly configured with 'transport input ssh'. Without it, SSH connections are refused even if the SSH server is running.
Candidates assume SSH is a global service that applies to all lines.
Mistake
An ACL on VTY lines always produces one specific, predictable symptom (either always a refusal, or always a timeout).
Correct
The exact behavior when a VTY ACL denies a connection can vary by IOS version and platform — sometimes producing 'Connection refused' (RST sent), sometimes a timeout (packet silently dropped). Verify against the specific device rather than assuming one fixed outcome.
Candidates often over-generalize a single observed behavior into a universal rule, when Cisco's actual documented behavior here isn't perfectly consistent across all IOS versions.
Mistake
You need to configure 'ip ssh' before generating RSA keys.
Correct
You must generate RSA keys with 'crypto key generate rsa' before SSH can be enabled. The 'ip ssh' commands come after.
Candidates reverse the order of configuration steps.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
It means the remote device actively rejected the TCP connection attempt to port 22. This typically indicates that no SSH server is listening on that port, or an ACL is blocking the connection. It is not a network reachability issue (which would cause a timeout) nor an authentication issue (which would cause 'Authentication failed'). To resolve, check SSH server configuration and VTY line settings.
To enable SSH, first configure a hostname (not default) with 'hostname R1', then a domain name with 'ip domain-name example.com', then generate RSA keys with 'crypto key generate rsa' (1024-bit minimum). Then enable SSH version 2 with 'ip ssh version 2'. Finally, configure the VTY lines with 'transport input ssh' and 'login local' (or AAA). Verify with 'show ip ssh'.
Common reasons: (1) The VTY lines are not configured with 'transport input ssh'. (2) An ACL on the VTY lines denies your source IP. (3) The RSA keys were not generated (check with 'show crypto key mypubkey rsa'). (4) The hostname or domain name is missing. Use 'show running-config | section line vty' and 'show ip ssh' to diagnose.
'Connection refused' generally means the destination host actively responded that nothing is listening on port 22 (or a policy rejected it) — often via a TCP RST. 'Timeout' generally means the client never received any response at all, suggesting the host or path is unreachable (e.g., a routing issue or a silently-dropping ACL/firewall). Ping can help narrow this down: if ping works but SSH is refused, the host is reachable but not accepting SSH; if ping also fails, connectivity itself is the more likely issue. Exact behavior can still vary by device and configuration, so use this as a general diagnostic starting point, not an absolute rule.
Generally, an ACL on the interface (e.g., inbound on the management interface) drops the TCP SYN without response, producing a timeout rather than a refusal. A VTY-line ACL (via access-class) can sometimes produce 'Connection refused' instead, since the router itself is processing the connection — but the exact behavior isn't perfectly consistent across every IOS version. For the exam, know both timeout and refusal are possible outcomes of ACL filtering depending on where and how it's applied, rather than treating either as an absolute, fixed rule.
If SSH is not enabled, the output will be minimal, e.g., 'SSH Disabled' or no output at all. If SSH is enabled, you'll see version, timeout, retries, and key information. Example: 'SSH Enabled - version 2.0'.
Most Cisco IOS devices have 16 VTY lines (0 to 15), but only a subset are configured by default (often 0-4). For SSH, you need to configure all lines you intend to use. Use 'line vty 0 15' to configure all. The number of concurrent SSH sessions is limited by the number of VTY lines and the 'ip ssh maxstartups' setting.
You've just covered Troubleshoot: SSH Connection Refused — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?