Setting up an account on dploy.io with your existing Digital Ocean droplet is a really smooth process, especially if you do it during the creation of your droplet. I ran into a little rough patch trying to congfigure dploy.io with my existing droplet, and I want to share the solution.

The trick here is to add the public key from dploy to your Digital Ocean server manually.  For those lucky enough to have the foresight of establishing their droplet with dploy.io at inception, it’s an easy click of the mouse. However, it took me a couple minutes to reverse my thinking of SSH keys to set up this configuration properly. It’s really simple once you realize what’s going on, but getting past the usual process of working with keys was my highest roadblock.

Keeping Our Keys Straight

This is a simple concept, but we’re probably not used to handling our SSH keys in this manner. Usually we have to generate our keys, then share our public key with a remote server so we can gain access. Well what’s happening here, is the reverse. Dploy.io has it’s keys generated, and wants to share it’s public key with you. Dploy needs us to hold it’s public key, so it can login with it’s private key and issue commands to pull our repository down to the server. So instead of just holding on to our ~/.ssh/id_rsa.pub key, we have to take the key being given to us and tell our server to allow access to the incoming user with the correct private key.

Allowing someone to access our server with not just a username and password, but with SSH keys needs to be configured on the server. I’m using a linux server, so that is why my paths are referenced the way that they are. But most, if not all Linux configurations, have the user’s “home” folder referenced with the tilda “~”. And the SSH keys are in a subfolder of the home folder called “.ssh”. So normally when we generate keys, this is where we’ll find them. There’s also another file in this folder that allows for remote access coming in to be permitted for the user. So suppose I want root to access my Digital Ocean droplet from dploy.io, I need to hold a public key on my server so dploy.io can login using their own private key.

And so it all boils down to this. Dploy.io has a link on your server setup to point you in the right direction, “Learn about public key authentication.“. Basically, we’re instructed to just add it to the “authorized_keys” file. I had an existing authorized_keys file I believe from my SSH access to the server, so I need to copy and paste the keys from dploy.io and add it to the file. Well that raised another question. What do they mean just add it to the file? Well without raising too much of a big deal, it’s just appending the file. So here’s what I did.

  1. I copied the public key from dploy.io
  2. nano ~/.ssh/dploy.pub
  3. Paste the key into this new public key file
  4. cat ~/.ssh/dploy.pub >> ~/.ssh/authorized_keys

Now the last command just appends the public key properly to the authorized keys file, and when I went back to dploy.io and tested my configuration my server finally worked.

Configure dploy.io with your existing Digital Ocean droplet

3 thoughts on “Configure dploy.io with your existing Digital Ocean droplet

  • November 28, 2014 at 4:34 am
    Permalink

    Hey, I’m trying to add a dPloy key to my server but it’s not working as I’m expecting.

    I log into my server, then type nano ~/.ssh/dploy.pub
    I then add the key from dPloy and try save it and it says the file doesn’t exist, do you know what could be causing this?

    Thanks, Harry.

    Reply
    • November 28, 2014 at 8:12 am
      Permalink

      Do you have a ~/.ssh folder on your server? If not, you may want to try generating some SSH keys with command:

      ssh-keygen -t rsa -C “your_email@example.com”

      Other than that being the problem, I can only think of permissions being an issue. But I wouldn’t see your home folder not allowing you permission. If you don’t need the statement above to create your keys, backup plan would be to use “sudo nano dploy.pub” to allow super user access. Again, this is probably not the issue.

      Reply
  • January 16, 2021 at 6:46 pm
    Permalink

    A big thank you for your post. Really looking forward to read more. Really Great. Feliza Garek Kiefer

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *