Help with users on secured droplet

trellis
1

I put in the sshd_permit_root_login: "no" directive into my group_vars/all file to help secure it. I did put a password hash into vars\sudoer_passwords.yml to allow for access to the admin user. The playbook ran with no issues, but it looks like it never created the admin user, and as a result, I don’t know how to get into my droplet as an admin now! I tried a regular su but I don’t know what password it’s using. My droplet is running fine, but I don’t know what to do at this point to be able to get into it to do admin related tasks (like run apt-get update and etc). Help is appreciated!

2

Is your users hash like the default, i.e., does it include admin_user?
If not, mind posting your hash?
If it is like the default, and if it includes a value in keys, could you try

  • SSHing to the server as admin to see if it connects: ssh admin@myip
  • running the server.yml playbook again to ensure that it can connect (it will try the admin_user if root has been disabled).

Note: The password in sudoers_passwords isn’t for accessing the server. It is for running sudo commands while already connected as the admin_user.

What were the cues that it didn’t create the admin user?

Sorry if I’m missing something, but does that mean you can connect to the server somehow, but are just unsure of the su password? The default password for admin to run sudo commands is example_password, as mentioned in the docs.

If you’ve disabled root login and the admin_user truly hasn’t been created or doesn’t have the right ssh keys, you may be victim to roots/trellis#294 which hasn’t yet been resolved.

3

I can SSH into the server as web just fine. Everything’s working. My clue that there is no admin user is that I tried su - admin when logged in as web and got an error that there is no user “admin”. Now I’m not sure what to do.

4

Looking at my group_vars/all file a bit more closely, it looks like I did not define keys for my admin user, which is why I can’t switch to it. Guess I did fall victim to that issue and I’m further guessing that my options here are limited.

5

So, if there is an admin user, but it just doesn’t have keys, I think you could login as admin via DO’s GUI console at

https://cloud.digitalocean.com/droplets/yourDropletNumber/console

(replace yourDropletNumber)
username: admin
password: example_password

Then you could add keys, or enable root login so you can use Trellis to reprovision, or whatever.

If admin was never created at all, I’m not sure whether that console will let you log in as root. I’ll need to spin up a droplet with those conditions and test

6

I’ve tested and you can restore access. It takes a few steps, so it’d be easier to just destroy the droplet and spin up a new one, if your situation can stand the downtime.

To restore access without destroying:

  • DO web GUI > Access > Reset Root Password
  • DO web GUI > Access > Console Access
    • username: root
    • type password emailed to you by DO (I had to type, couldn’t paste)
  • It will require you to change root password
    • at the prompt retype the existing password (the one emailed above)
    • type new password
    • retype new password
  • vim /etc/ssh/sshd_config
    • PermitRootLogin yes
    • save and exit vim editor
  • service ssh restart
  • add admin_user to users hash, and add keys (ssh keys docs)
  • run server.yml again

Then everything should be normal. I hope you’ll report back so we know what is possible and what comes up in a critical situation like this. Thanks!

6 Likes
7

Those steps worked perfectly. I was able to get back in as root without destroying the droplet!

8

roots/trellis#345 should help prevent this scenario. Thanks again for reporting this @romero2k.