I accidentally attempted to SSH into one of my servers from a device that did not contain my ssh key. I configure all of my servers to only allow authentication via cryptographic keys. Root ssh as well as password auth are disabled.

To my surprise, I was able to log in to my server with a password despite this. Baffled, I first tried some other servers. 2 of the 5 other servers I tried were accessabke via password.

After some swift investigation the culprit was found, a cloud-init ssh config in sshd_config.d/ with one line: password_authentication Yes.

So TLDR PSA…if you run a server in any type of virtualized environment, including a VPS, check your /etc/ssh/sshd_config.d/ folder. And more broadly, actually thoroughly test your ssh access to confirm everything is working as you intend it to.

  • Boris_NotTooBadinoff@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    18 hours ago

    Had a similar issue with tlp recently. I just happened to notice the laptop battery was at 100%, and said it was charging. I double and triple checked the config file, but the tlp-stat -b still showed the thresholds at 90%-100%.

    Turns out tlp, at some point, started ignoring /etc/tlp.conf, and was pointing to /etc/default/tlp

  • henfredemars@infosec.pub
    link
    fedilink
    English
    arrow-up
    18
    ·
    edit-2
    2 days ago

    This is good advice in general. Think of it like penetration testing. You really should verify what you can actually access remotely on a device and not assume you have any level of protection until you’ve tried it.

    Log files can also contain signs of attack like password guessing. You should review these on a regular basis.

  • pe1uca@lemmy.pe1uca.dev
    link
    fedilink
    arrow-up
    8
    ·
    1 day ago

    I could even go further into saying: always test every change you make, do not assume the change has been made because you updated a file.