2

I've read many SSH connection refused posts on here and will continue to pour through them after writing, but instead of blindly trying each solution hoping it works out for my computer, thought I'd write out my troubleshooting solving process.

Goal: use ssh to root log into my server

Problem:

$ ssh [email protected]
ssh: connect to host 123.456.78.911 port 22: Connection refused

Context Server: Digital Ocean (Virtual Machine - the $5 a month deal)
OS: Windows 10, Linux Subsystem, Ubuntu Bash, Linux Subsystems
OpenSSH - client and server both installed
Firewall - SSHD added to allowances (both in and out)

Inbound Rules - blocked public networks as recommended enter image description here

Troubleshooting Process

  1. Set up new SSH keys on Digital Ocean
  2. ssh is running ssh running
  3. i've got the right port set up Windows Port 22 Listening enter image description here

Edit: adding verbose mode output

ssh -v [email protected]
OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to xxx.xxx.xx.xxx [xxx.xxx.xx.xxx] port 22.
debug1: connect to address xxx.xxx.xx.xxx port 22: Connection refused
ssh: connect to host xxx.xxx.xx.xxx port 22: Connection refused

Leads
I've connected to my server on this computer before, but had to factory reset earlier this month. Had trouble the first time and I can't remember how I solved it (this was a year ago). I'm pretty sure ssh is enabled on the DO server side, so my guess is that the private and public keys are misplaced and I have to change a file path somewhere. I remember there was an issue with file locations using Ubuntu in Windows.

Do I have to add the public and private keys to some other authorization file? or key location?

Improve this question
3
  • 3
    First, thanks for documenting in detail what you did, too few questions do this (but please do text copy-and-paste next time, no pictures, because text can be searched). Second, "connection refused" is probably a network/firewall issue. Try disabling the Windows Firewall completely (only for the test), also have a look at Digital Ocean's network/firewall settings (I am not familiar with Digitial Ocean). Third, to debug actual key problems etc., use verbose mode, both on the client (ssh -v) and server (configuration file, or run sshd directly with options, and not as service). Commented Dec 6, 2020 at 8:31
  • Hi @dirkt, thanks for your advice. I'll make sure to copy paste instead of use pictures next time. I tried disabling firewall and saw that i don't have any firewall set up on digital ocean, but still no go. Thanks for sharing that verbose mode tip, I've added output above Commented Dec 7, 2020 at 7:19
  • Tho I'm not sure what you mean when you say run sshd directly with options, not as a service. Commented Dec 7, 2020 at 8:05

2 Answers 2

Reset to default
1

First: understand the fundamentals of what is supposed to happen.

A SSH client process on your Windows desktop is supposed to connect to TCP port 22 on the DigitalOcean VM. Once a connection is established, it should authenticate as user root using a SSH key.

That means you don't need sshd (or "ssh service") on your desktop: it would be needed only if you wanted to allow inbound SSH connections to your desktop.

You're getting "connection refused". That means one of the following:

  • you might not have the correct IP address for the cloud VM (with cloud VMs, the local IP address the VM sees internally might not be the same as the address presented to the internet by the cloud infrastructure)
  • your local network might require the use of a proxy to access services outside the local network (common in workplace networks)
  • the Digital Ocean VM might not be running at all
  • the VM's firewall in the cloud might not be allowing incoming SSH connections until you specify the allowed source IP addresses
  • you might have to use Digital Ocean's web UI/API to enable the SSH service on the cloud VM.

Once you can establish a basic TCP connection to the VM's SSH port, you can proceed to troubleshooting the authentication.

Allowing password-authenticated logins on a cloud VM is a very bad idea if access to the SSH port is not restricted to known IP addresses only: there are hacked servers and automated malware that will spend all their time scanning the internet for SSH-enabled hosts and attempting to bruteforce any well-known user accounts, including root.

sshd (the SSH service) even has a special setting that can force direct logins as root to either always be rejected, or to accept key authentication only, even though password authentication may be enabled for other users. Use of that setting is strongly recommended for cloud services.

If a VM is maintained by several people, logging in using a personal user account and then using sudo makes it easier to use the logs to find out who-did-what if it ever becomes necessary. A cloud provider may require that you use a particular user account that is not root for initial login; once you successfully connect for the first time and get your root access, you can obviously configure the VM as you see fit.

Often, a cloud provider will give a pre-generated SSH private key for initial SSH access to the VM. There are a few possible key file formats: a *.ppk file is for PuTTY, a common free Windows SSH client (nowadays also available for Linux), while id_* with no specific suffix is for OpenSSH. Usually the keys can be converted from one format to another using the respective key generator tools (like PuTTYgen keyfile.ppk -O private-openssh -o id_openssh for converting *.ppk files to OpenSSH format).

If you are using WSL's command-line SSH client, that is a form of OpenSSH. Normally OpenSSH looks for default private keys in the .ssh sub-directory of the local user's home directory (named id_rsa, id_dsa, id_ecdsa, id_ed25519 etc. according to the algorithm used). If any of those private key files exist, the client will automatically offer them to the remote server if it allows key-based authentication.

On WSL, the location of the Unix-style home directory might not be so obvious, so you might want to use the -i option to explicitly specify the private key file to use.

When using key authentication, you must still specify the correct username, so the SSH command might look like:

ssh -i /some/where/id_digitalocean_privatekey [email protected]
Improve this answer
1
  • Sorry for the late reply, turned out an incredibly noob issue. Line 2 of the config file, which is usually automatically commented out, was not. I must have accidentally deleted the # at some point. Now its working perfectly. Thank you for your well thought out response, I learned how to frame the problem before thinking through different solutions. Commented Jan 22, 2021 at 3:56
-2

Well first of all. DO NOT use this setup. Actually you do not want to use those MACs at all!

Did you try to enable password authentication? Just to see if this works? Also did you check /var/log/auth.log? Did you increase the verbosity of the sshd logging in /etc/sshd/sshd_config?

For me it looks more into the direction, that the sshd daemon is not correctly listening on port 22. Thats why you get a connection refused. you can check with nmap if that port is realy open.

sudo nmap -sSV -O -p 22 -v9 destination_IP
Improve this answer
3
  • by MACs do you mean the inbound outbound rules? Password authentification is set to 'yes' on the config file, but no i haven't checked the auth.log yet. will try those. I tried to nmap but got a notification saying that it doesn't work properly on windows linux subsystem and to do a native install. Will try the other steps first. thanks Commented Dec 7, 2020 at 8:06
  • MAC= Massage Authentication Code. MD5, SHA-1 is considered as broken and should not be used anymore. Better example: MACs [email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,[email protected] Commented Dec 7, 2020 at 14:13
  • And about that password auth should not be used is just nonesense. Noone will ever try to bruteforce a secure password. Well known passwords might be used by scans of bots. That's it. Don't believe me? Setup a honeypot and check yourself Commented Dec 7, 2020 at 14:21

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.