Today I explored ssh-audit, a tool designed to audit SSH configurations. Although it’s an excellent tool, I found the hardening guides somewhat lacking. Hence, I decided to write a detailed walkthrough, ensuring the ssh/sshd configurations are easily readable.
  • RegalPotoo@lemmy.worldEnglish
    82·
    1 year ago

    Cool,.but from the post it seems like all it does is:

    • Recommend disabling old algorithms, which you would have already done if you followed a modern hardening guide like https://infosec.mozilla.org/guidelines/openssh
    • Detect if you are running a known-vulnerable version of OpenSSH, which wouldn’t be an issue if you keep good patch hygiene and install your SSH server through you operating systems’ package manager

    So what’s the point? Who is this for?

    • jwhardcastle@dmv.socialEnglish
      141·
      1 year ago

      Scripting, to confirm that a large fleet of boxes are all running according to your policy. Verification that the config you want is actually the config you have.

  • PureTryOut@lemmy.kde.social
    4·
    1 year ago

    Personally I made sure SSH is only accessible when connected through a VPN setup for that purpose. As in, that same machine hosts a Wireguard setup (through Tailscale) and you need to connect to that first before SSH is available. And then SSH also only accepts key-based authentication. I don’t think I need more than that?

      • PureTryOut@lemmy.kde.social
        1·
        1 year ago

        I have a VPS that runs the main proxy which I can always access via a console on the website of the company I’m renting it from (Hetzner). The other machines run locally in my home so I can just plug in a cable if need be.

      • PureTryOut@lemmy.kde.social
        1·
        1 year ago

        Sure but I rather not have the SSH port open to the world, it just makes it harder for attackers to get in this way. Besides I use the VPN for more things, some self-hosted services I don’t want accessible by the whole world.