Based on the provided information, it is my opinion that one or more of these is true:
- The server’s networking is down.
- The SSH service is listening on a different port (not 22).
- The server’s firewall has the SSH port blocked for inbound traffic.
- The client computer has SSH port blocked for outbound traffic.
- Something like fail2ban on the server blocked your IP for a period of time after a few failed logins.
I can’t say for sure which or which combination, but the timeout provides a clear indication that it is not directly based on login at that stage (though #5 would imply that it was in previous errors). Let’s break those possibilities down a bit.
+1. Ping the droplet, see if you get a response. While firewall can block ping too, I doubt you’ve done anything to block ICMP packets. It’s just not common behavior. https://www.wikihow.com/Ping-an-IP-Address
If this fails, refer to https://www.digitalocean.com/community/questions/having-trouble-with-the-network-on-your-droplet
+2. Log in via web console and run this:
Do you see SSH? Is it on port 22? If not, try using the other port. If it is, move on. If it’s on another port and still fails the same, move on as well.
+3. Open the port. Let’s assume 22 from this point forward, though use your findings in #2 to inform otherwise.
iptables -I INPUT -p tcp --dport 22 -j ACCEPT
ufw allow 22/tcp
At least one of those works, worst case scenario one fails.
+4. Try disabling any firewall software on your computer. https://www.wikihow.com/Turn-Off-Firewall
+5. Try overriding something like fail2ban.
- Find your IP here: https://ifconfig.me/
- If your IP were 220.127.116.11, then run:
iptables -I INPUT -s 18.104.22.168 -j ACCEPT
Hope that helps :)