Context: I’m effectively new to DO. I’ve used it here n there in the past but there always seemed to be someone else on the team who was primarily responsible for such things. It happens :) The point is, assume I know less (not more). From my POV you can’t speak / type too slowly :) Thanks.

In any case, I’ve inherited a project / client from another dev / team that is no longer available.

I’ve poked around in /etc/ssh via the console button in the DO CP.

Also, I’ve read:

Long to short, I presume I should remove anything from /etc/ssh and start that process over. Else, again as I understand it, anyone previous who had SSH access actually still does.

Maybe there’s also a tutorial on this situation? I can’t be the first new dev on an long time DO account / droplet, eh :) It’s a new project / client so I’m treading lightly. That said, this needs to get sorted out sooner rather later. Any help is greatly appreciated. Again, please type slowly :)

Submit an answer

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!

Sign In or Sign Up to Answer

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.

Bobby Iliev
Site Moderator
Site Moderator badge
June 9, 2023

Hi there,

I totally understand the situation you’re in, I’ve also inherited projects like this in the past!

Let’s start by saying that you should not delete the /etc/ssh directory. This directory contains the configuration files for your SSH server (sshd_config) and SSH client (ssh_config), as well as the server’s host keys. Deleting these files could result in the SSH service failing to start, or in the loss of the server’s unique identity, which can cause security warnings the next time you try to connect.

With that out of the way, let’s break down the steps you need to secure your SSH access!

  1. Make sure to take a backup of your Droplet before making any changes, that way if anything goes wrong, you will be able to revert to a working version of the server.

  2. After that, you can move to creating a new SSH Key: On your local machine, create a new SSH key pair. You can use the ssh-keygen command to do this. Here’s a basic example:

    ssh-keygen -t rsa -b 4096 -C ""

    This will create a new RSA key pair with a key length of 4096 bits. You’ll be asked to provide a file in which to save the keys. You can press enter to use the default location if you don’t already have an SSH key there. You’ll also be asked to provide a passphrase. This is optional but recommended for additional security.

  3. Add the Public Key to DigitalOcean: Login to your DigitalOcean account, go to the “Security” section in your account settings, and add the newly created public key (the file ending in .pub) to your account.

  4. Remove Old SSH Keys: Also in the “Security” section, you’ll see any other SSH keys that have been added to your account. You can remove any keys you don’t recognize or know are no longer needed.

  5. Add the Public Key to the Server: On your Droplet, edit the ~/.ssh/authorized_keys file for each user that will be logging in via SSH (including root, if root logins are permitted). Remove any existing keys that should no longer have access to the server and add your new public key.

    An example command to do this is:

    echo "ssh-rsa AAAA..." >> ~/.ssh/authorized_keys

    Replace “ssh-rsa AAAA…” with your public key.

  6. Secure the SSH Configuration: Edit the /etc/ssh/sshd_config file on your server to secure your SSH configuration. Here are a few recommended settings:

    PermitRootLogin no
    PasswordAuthentication no
    AllowUsers yourusername

    The first line disables logging in as root via SSH, the second line disables password authentication (forcing key-based authentication), and the third line specifies which users are allowed to login via SSH.

    After making these changes, restart the SSH service with:

    sudo service ssh restart
  7. Test Your Changes: Try logging into your server via SSH from your local machine. If you’ve set everything up correctly, you should be able to log in without any issues.

Please note, it’s a good idea to keep the DigitalOcean console open while you’re making these changes. If something goes wrong with the SSH configuration, you could get locked out of your Droplet, but you can still access it via the console.

Remember, these are general steps and may need to be adjusted based on your specific setup.

If you run into any issues, feel free to ask for more detailed instructions.

Hope that this helps!



Try DigitalOcean for free

Click below to sign up and get $200 of credit to try our products over 60 days!

Sign up

Featured on Community

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.

Welcome to the developer cloud

DigitalOcean makes it simple to launch in the cloud and scale up as you grow — whether you're running one virtual machine or ten thousand.

Learn more
DigitalOcean Cloud Control Panel