No SSH access & SSH is a holy mess....

November 18, 2019 493 views
Ubuntu 18.04 Security

I have a website server running on this droplet. Specifically Vesta CP, WordPress running on Ubuntu 18.04, which was originally hardened to only accept the following factors: my user, my password, and my key. I don’t know what is going on with it now. It started with refusing to accept my SSH key. I logged in via the console to see what the problem was. My user’s .ssh directory was gone, it now had a single file named ssh in the home folder, there was idrsa.pub in the home folder, and authorizedkeys was in the home folder as well. I tried to reconstruct the directories but to no avail. I even created new keys and used FTP to sync the server up with my pc. I went into ssh_config and checked the settings, tried to change it to a password only and do away with the key authentication. Now it keeps saying the connection was reset by a peer.

I’m completely, utterly lost at this point, and cannot seem to find any documentation in Google that applies to this situation at all. As far as the server being compromised, I haven’t seen any signs that it has been accessed by someone else. Do droplets depreciate over time or something?

2 Answers

Hello,

I think that you have to change the permissions of your .ssh folder to 700 and the permissions of your authorized_keys file to 600 in order to be able to connect, otherwise the server would refuse the key due to weak permissions.

If this does not help, what I could suggest is trying to ssh with a -vvv argument which would essentially provide you with more information on why the connection is being refused.

Droplets do not really get deprecated, but Operating Systems kind of do. Most operating systems have a so-called ‘End of life (EoL)’.

'End of life (EoL)’ is when a software reaches the end of its designated support period. So for example Ubuntu 14.04 EOL is 2019-04-25, so if you have an Ubuntu droplet it’s better to upgrade your distribution as you would no longer get security updates and etc.

Regards,
Bobby

I would suggest stopping/restarting SSH after you fix/verify perms of your .ssh directory.

Also, any time you change ssh_config, plan on bouncing SSH.

Have another answer? Share your knowledge.