Asking for password for root after deploy

I have a problem I can’t fathom on one site I’m working on. After my latest deploy to staging I can’t ssh as root without it asking me for a password (which I don’t have as it should just use the key on the DO droplet?) Anyway, it’s only affecting this one site and only on staging. Other sites I can connect as root to staging without a password.

The only thing I have done is change the git branch of the staging instance to a feature branch, but I’ve done that before on other builds without issue.

Any pointers as to what is going on and how I can get connected?

I’ve already emptied known hosts file in case that was causing an issue, power cycled the droplet and re-deployed… but the behaviour is the same.

Thanks in advance!

I think most DO droplet dashboards include Console Access and Rest Root Password buttons under the “Access” submenu. I would think those might come in handy to gain access and check whether something is amiss in ~/.ssh/authorized_keys. If everything looks good there then check your client side keys.

Hello - I reset the root access pass word and looked at the authorized key file and can see the key that corresponds to my key there.

Even If I input the password I just reset for root when trying to connect I still can’t get in from local ssh via terminal or sequel pro though…

Not sure what to add here but afaik Trellis is not setup to change your root pass or tinker with your authorized keys autonomously.

@chris2020 I realize you probably already know the stuff I’ll mention, but just to be sure…

Any chance your branch has sshd_permit_root_login: false? If so, and you ran server.yml, then root login will be disabled (related docs). If so, now you would need some adjustments:

  • Any time your run server.yml include the -K (i.e., --ask-become-pass) option and use the admin_user sudoer password (default is example_password)

  • Any time you need to ssh, don’t use root. Use the admin_user (default admin) who can sudo, or use the web_user (default web) if you will be dealing with files in the web_root (owned by web_user).

If you want to reenable root, change back to sshd_permit_root_login: true then run
ansible-playbook server.yml -e env=staging -K --tags sshd
then all should be back to normal.

If it is not an issue of sshd_permit_root_login being set to false, then you could potentially use the Console Access to check that /etc/ssh/sshd_config on your remote has PermitRootLogin yes. If you have to change it to yes, follow the edit with service ssh restart.

Otherwise, Yes it seems likely your ssh key is not being used/found and the connection is falling back on password authentication. You could just double-check that your ssh-agent has it loaded with the old
ssh-add -l
The key should be listed in output. If not, add it with just ssh-add (or ssh-add -K on OS X).

You also might glean some information with a verbose ssh attempt:
ssh -v

The output should include a line indicating that your relevant key is being offered, e.g.,
debug1: Offering RSA public key: /Users/philip/.ssh/id_rsa

Sometimes I forget my head is screwed on.

I had indeed locked down the security - I overlooked that this effects staging as well as production. I had some old credentials stored in my sequel pro connection.

Switching from root to the correct user with the correct password worked.

Thanks as always for helping out.