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!
I put in the
users hash like the default, i.e., does it include
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
adminto see if it connects:
- running the
server.ymlplaybook again to ensure that it can connect (it will try the
roothas 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
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.
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.
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.
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
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
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
- save and exit vim editor
service ssh restart
usershash, and add
keys(ssh keys docs)
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!
Those steps worked perfectly. I was able to get back in as root without destroying the droplet!