Tencent Cloud Business KYC Benefits Troubleshooting Tencent Cloud SSH Connection Timeout

Tencent Cloud / 2026-07-07 12:51:02

Why SSH Connection Timeouts Happen on Tencent Cloud

An SSH connection timeout usually means the client cannot reach the server’s SSH port in time. On Tencent Cloud, that can be caused by network path issues, security policies (security group or firewall), instance settings, routing/NAT behavior, or even a mismatched SSH configuration. The most effective troubleshooting approach is to stop guessing and test step by step from the network layer upward.

This guide walks you through a practical, repeatable checklist focused on Tencent Cloud. You can apply it whether you’re connecting from your laptop, a CI runner, or another server.

What You Should Collect Before Troubleshooting

Before changing anything, gather a few key details. These reduce downtime and prevent you from chasing the wrong cause.

Record the exact symptoms

Write down:

The SSH client command you used (including port number).
The exact error message (e.g., Operation timed out vs Connection refused vs Permission denied).
How long it waits before timing out.
Your source public IP (if applicable) and where you run the SSH client from.

Confirm the instance and network information

Check these in Tencent Cloud console:

Instance ID and region/availability zone.
Whether you are connecting to the public IP or an internal IP.
SSH port (commonly 22, but you might have changed it).
Security group name/ID attached to the instance.

Also note the operating system (Linux/Windows isn’t relevant here, but Linux distro can change where sshd config lives).

Tencent Cloud Business KYC Benefits Step 1: Distinguish Timeout From Other SSH Errors

This matters because each error points to a different layer.

Timeout usually means “cannot reach port”

If your SSH client says “Operation timed out,” “No route,” or it just hangs and times out, it’s typically:

Tencent Cloud Business KYC Benefits The port is blocked by security group/firewall.
The instance has no public route / wrong IP.
The sshd service is not listening on that port.
Network ACL or OS firewall is dropping packets.

Connection refused is different

If you get “Connection refused,” the network path works and something actively rejected the connection. That often means sshd is not running or is listening on a different port.

Permission denied means networking is fine

If you reach the server and get “Permission denied (publickey/keyboard-interactive),” connectivity is working. That’s an authentication/authorization issue, not a timeout.

Step 2: Verify You’re Targeting the Correct IP and Port

Tencent Cloud Business KYC Benefits On Tencent Cloud, confusion between public and private IPs is common. Your client may be using the wrong address or port.

Confirm public IP vs private IP

If you connect from your local computer over the internet, you generally need the public IP (or a Bastion/Jump host).
If you connect from inside the same VPC, the private IP can work—provided routing and security rules allow it.

Confirm the SSH port in both places

Check the port configured on the instance. If your Tencent Cloud security group allows only port 22 but you changed sshd to 2222, you’ll hit timeouts.

From the client side, ensure you use the correct command, for example:

ssh -p 22 user@PUBLIC_IP
Tencent Cloud Business KYC Benefits ssh -p 2222 user@PUBLIC_IP

Step 3: Test TCP Reachability From Your Client

A timeout is easiest to interpret when you test the port directly. You want to know whether traffic can reach the server at all.

Use a simple TCP check

From your machine, try one of these approaches:

If you have nc (netcat): nc -vz PUBLIC_IP 22
If you have telnet: telnet PUBLIC_IP 22

Interpretation:

Success: TCP reachability is fine; the problem is likely sshd/service or credentials.
Timeout: Something blocks the port on the path (security group, OS firewall, routing, or wrong IP).
Immediate refusal: The port is reachable, but nothing is listening.

Step 4: Check Tencent Cloud Security Group Rules

On Tencent Cloud, the security group is often the main culprit for SSH timeouts. You need an inbound rule that allows TCP to your SSH port from your source IP or range.

Locate the correct security group

Open the instance details and check which security group is attached to the NIC (network interface). If you have multiple NICs, verify the correct one.

Create or adjust inbound rules

You generally need an inbound rule similar to:

Protocol: TCP
Port: 22 (or your custom port)
Source: your public IP (best) or a trusted CIDR range
Action: Allow

Common mistakes:

Allowing from 0.0.0.0/0 (not recommended, but sometimes used for testing).
Tencent Cloud Business KYC Benefits Allowing a different port than sshd uses.
Using the instance’s private IP as the source/target rule without realizing inbound rules filter by source IP on that network boundary.
Adding rules to a security group that isn’t actually attached.

Consider rule precedence and limits

Some setups have multiple security groups or additional network filtering. Even if the rule looks correct, confirm it applies to the active network interface and port.

Step 5: Verify the Instance OS Firewall and sshd Listener

Even with correct security group inbound rules, the instance operating system can still block SSH with a local firewall, or sshd may not be listening.

Check whether sshd is running

On the instance (via console, serial console, or another method), inspect:

Whether the SSH daemon is active.
Whether it’s listening on the expected port.

Typical checks (Linux):

sudo systemctl status sshd (or ssh on some distros)
sudo ss -tlnp | grep ':22' (adjust port)

Tencent Cloud Business KYC Benefits Confirm sshd binds the right interface and port

If sshd is configured to bind to localhost only, external connections will fail and often appear as timeouts. Check sshd configuration (commonly /etc/ssh/sshd_config), especially:

Port
ListenAddress
AllowUsers/DenyUsers (for auth failures, not timeouts)
PermitRootLogin (also for auth)

For timeouts, pay attention to Port and ListenAddress.

Check OS-level firewall (iptables/firewalld/ufw)

If a local firewall blocks the port, traffic will drop. You can test by verifying rules that affect inbound TCP on your SSH port.

Common checks:

For firewalld: sudo firewall-cmd --list-all
For ufw: sudo ufw status
For iptables/nftables: list rules for INPUT chain and port matches

If you enabled a firewall rule long ago, it may not match your current SSH port.

Step 6: Check Routing, Public IP Availability, and NAT/Bastion Requirements

Sometimes the security group is fine, but the network path still fails. On public cloud, routing and access design matter.

Make sure the instance actually has a reachable public IP

Confirm that:

The instance has an assigned public IP (Elastic IP equivalent or standard public IP depending on your setup).
The public IP is in the same region/network where you think it is.
You are not using a stale/old IP after re-creating or reconfiguring the instance.

If the instance is private-only, use a jump host

If the instance does not expose a public IP, SSH from the public internet will time out. In that case, you need one of these patterns:

Tencent Cloud Business KYC Benefits Use a Bastion/Jump host in the same VPC with public access.
Use VPN/Direct Connect with appropriate routing.

Attempting direct SSH to a private IP from outside will not work unless you have routing set up.

Verify subnet and route tables

Within a VPC, routing tables decide where packets go. If you recently changed subnets or route entries, confirm:

Your source network can route to the instance subnet.
No default route conflicts exist.
NAT gateways or route-based access isn’t misconfigured.

Step 7: Test From Another Host Inside the Same VPC

If you suspect the issue is path-related rather than instance-specific, try testing connectivity from a different machine that has network reachability to the same subnet.

Internal connectivity test

Run a TCP port test from another ECS/VM inside the same VPC/subnet (or same network context). If internal tests succeed but public tests fail, the problem is likely public access design, security group rules for external sources, or lack of public IP.

Internal test outcomes

Internal works, external times out: security group source rules or public IP exposure issue.
Internal also times out: likely OS firewall, sshd not listening, or security group rules restricting internal ranges.

Step 8: Common “Looks Like a Timeout” Mistakes

Some issues don’t strictly block TCP at the port but still make it feel like a timeout due to handshake delays or client behavior. Watch for these.

Wrong SSH port or service mismatch

Tencent Cloud Business KYC Benefits If you configured security group for 22 but sshd is on 2222, you’ll get timeouts. Similarly, if sshd is disabled and some other service occupies the port, behavior changes (refused vs timeout).

DNS or IP formatting mistakes

If you used a hostname or wrong IP, you might be targeting a non-existent route. Prefer numeric IPs during troubleshooting.

IPv6 vs IPv4 confusion

If your client resolves to an IPv6 address but the instance only supports IPv4, connections can fail oddly. Force IPv4 in your SSH command if needed (for example by using the IPv4 literal rather than a hostname).

Step 9: If You Can Reach the Port, Check Authentication and Permissions

Once you confirm TCP connectivity and that sshd is listening, timeouts usually disappear. Remaining failures are authentication or policy problems.

Permission denied is not a timeout, but it blocks access

Common causes:

Wrong username.
Wrong private key.
Key not added to authorized_keys.
Permissions on home directory or .ssh are too open, causing ssh to ignore the key.

But again, these lead to “Permission denied,” not a timeout.

Check whether you blocked all users

In sshd config, directives like DenyUsers or AllowUsers can prevent your login even though the service is reachable.

Practical Troubleshooting Playbook (Fastest Path)

If you want the quickest route to resolution, follow this exact order.

1) Confirm you’re using the correct IP and port

Use the public IP for public internet access, and match the port to sshd configuration.

2) Test TCP reachability

From your client: nc -vz or telnet to the target port.

3) Fix security group inbound rules

Allow TCP on the SSH port from your source IP (or your office/VPN CIDR). Confirm the security group is attached to the active NIC.

4) Verify sshd is running and listening

On the instance: check service status and listening port.

5) Check OS firewall

Allow inbound TCP on the SSH port and reload firewall rules if needed.

6) Re-test, then proceed to authentication

If the port connects but login fails, resolve key/user permissions.

When You Don’t Have SSH Access: Use Console/Recovery Methods

Sometimes SSH is the only management channel you don’t have. When timeouts happen, you still need a way to regain control.

Use the cloud provider’s web console/serial console

With console access, you can:

Check sshd status and logs.
Inspect firewall rules.
Edit sshd configuration and restart the service.

Check logs for confirmation

In Linux, sshd logs usually live under system logs. If the service starts but never gets far enough, logs can clarify whether it’s listening, refusing, or blocked internally.

Security Group and Firewall Settings: A Safe Testing Approach

During troubleshooting, it’s tempting to open SSH broadly. That can be risky. A safer testing approach is to temporarily allow only your current public IP and only the required port.

Use narrow source CIDR

Tencent Cloud Business KYC Benefits Prefer your specific public IP (/32) or a trusted VPN CIDR. After success, tighten again.

Keep changes minimal

Change one layer at a time. For example:

If you modify security group rules, test after applying.
Tencent Cloud Business KYC Benefits If you adjust sshd port, ensure both security group and OS firewall are updated.

Conclusion: Timeout Fixes Come From Layer-by-Layer Testing

SSH timeouts on Tencent Cloud are rarely random. They are almost always caused by a mismatch between what your client is trying to reach and what the network and instance are actually allowing. Start by confirming the correct IP/port, then test TCP reachability, verify security group inbound rules, ensure sshd is listening, and finally check OS firewall rules.

If you follow the playbook in order, you’ll usually pinpoint the root cause quickly—without risky trial-and-error or wide-open firewall changes.