SSH connection gives timeout, was working a day ago

Question

Here's the situation. SSH was working perfectly fine until a day ago. I didn't do anything out of the ordinary. I was able to putty into my server, use git over ssh, etc.

But now I can't do any of that. The error is persistent and common across all SSH clients and devices I use (putty, git bash, cmder, etc). The error of course is connection timeout. And here is what I have tried so far.

• ssh -vvv mydomain.com doesn't return anything useful, just the same error after a bunch of useless stuff.
• Tried disabling the windows firewall (Duh). No cake.
• Checked and made sure my server is still serving on :22. Git connection to bitbucket isn't working anymore either, mind you.
• Tried it on different device (my laptop). Still connection timeout. (So OS is probably not at fault here).
• Tried resetting the router. No cake.
• Changing the internet connection does make the problem go away.

So maybe the ISP blocked the 22 port? But it was working yesterday. And also how do I make sure the problem is on ISP's end?

Answer 1

It would be unusual for an ISP to block outgoing SSH connectivity, i.e., outgoing connections with a destination port of TCP port 22, but you can test that from one of the client systems, e.g., by using PuTTY to attempt to connect to port 22 at portquiz.net; the portquiz.net server listens on all TCP ports, allowing you to test any outbound TCP port. You should see a username and password prompt from the portquiz server.

You mentioned that you don't believe there is a problem at the server end, since you can connect to the SSH server from another location. Since firewall software can block on specific IP addresses or address ranges, you should verify that it isn't blocking on the IP address assigned to your systems by your ISP; you can visit www.whatismyip.com to determine your currently assigned external IP address. If the server is using iptables for firewall capabilities, see How To List and Delete Iptables Firewall Rules.

Usually, one wouldn't expect some firewall block to be put in place without you specifically requesting it, but if the server is running Fail2ban or some similar intrusion detection system (IDS) software, if you inadvertently mistyped your login credentials several times when attempting to logon by SSH, it is even possible that your IP address was banned from SSH connections at the server, though the ban might be a temporary one. If the server is running Fail2ban, check its log file, likely at /var/log/fail2ban.log; if the address is there you can unban the IP address.

Do you have access to the server from the client systems on other ports? E.g., if the server is functioning as a web server can you connect to port 80 and/or 443 from the client systems? Or port 25, if it is functioning as an email server. Can you ping the server from the client systems? If you don't have any access to other ports when you would expect to have such access, if there's not a block at the server of your IP address, perhaps there's a problem with network connectivity between your ISP and the server.

Wireshark is a very useful tool for troubleshooting connectivity problems. It is free and available for a variety of operating systems, including Microsoft Windows. You could install it on one of the client systems and observe the network traffic between your systems and the server. It can capture and display all network traffic between the system on which it is run and other systems; to isolate just the traffic between the client system and the server, you can configure Wireshark to filter by port number, e.g., 22, or IP address. There's also the command-line tool, WinDump, which is the equivalent of the commonly used tcpdump utility on Linux systems, but since Wireshark provides a graphical user interface (GUI), it will be easier to analyze the traffic with it. With a packet analyzer, such as Wireshark, you could determine if the client system is seeing any packets from the server or if the traffic is all one way, i.e., from the client to the server.