I disconnected from server and could not connect to it anymore after setting up a program running on server today, when i try to login I get following error: ssh abc@67.xxx.xxx.xxx ssh: connect to host 67.xxx.xxx.xxx port 22: Connection timed out
verbosity mode: ssh abc@67.xxx.xxx.xxx -vvv OpenSSH_7.2p2, OpenSSL 1.0.2g 1 Mar 2016 debug1: Reading configuration data /etc/ssh_config debug2: resolving “67.xxx.xxx.xxx” port 22 debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to 67.xxx.xxx.xxx [67.xxx.xxx.xxx] port 22. debug1: connect to address 67.xxx.xxx.xxx port 22: Connection timed out ssh: connect to host 67.xxx.xxx.xxx port 22: Connection timed out how to solve it???
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Get our biweekly newsletter
Sign up for Infrastructure as a Newsletter.
Hollie's Hub for Good
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Become a contributor
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
i found the problem: the program i run took too many memory and CPU and whole system just died. I had to go to console on digitalocean to reboot the droplet and problem fixed
Hi @zz386 Can you login via the Console on the control panel on DigitalOcean? Seems like something might have crashed your SSH daemon or maybe the firewall was enabled.
I resolved it. It turns out that when we create a droplet using the digital ocean UI, there is a section near the bottom which allows you to pick the SSH key that you have already added to your account. That step is not obvious when you haven’t set up SSH keys yet on digital ocean and start by creating your first droplets. So I erased existing droplets, and created new ones again, this time with the SSH key that I had set up in advance. Now my SSH sessions start up fine on the droplets.
Probably there is a way to fix it without the above steps, but I couldn’t get that to work: ssh-copy-id username@remote_host fails because ssh username@remote_host already fails (in my case, connection timed out).