cross-posted from: https://infosec.pub/post/10908807

TLDR:

If I use SSH as a Tor hidden service and do not share the public hostname of that service, do I need any more hardening?

Full Post:

I am planning to setup a clearnet service on a server where my normal “in bound” management will be over SSH tunneled through Wireguard. I also want “out of bound” management in case the incoming ports I am using get blocked and I cannot access my Wireguard tunnel. This is selfhosted on a home network.

I was thinking that I could have an SSH bastion host as a virtual machine, which will expose SSH as a a hidden service. I would SSH into this VM over Tor and then proxy SSH into the host OS from there. As I would only be using this rarely as a backup connection, I do not care about speed or convenience of connecting to it, only that it is always available and secure. Also, I would treat the public hostname like any other secret, as only I need access to it.

Other than setting up secure configs for SSH and Tor themselves, is it worth doing other hardening like running Wireguard over Tor? I know that extra layers of security can’t hurt, but I want this backup connection to be as reliable as possible so I want to avoid unneeded complexity.

  • marcos@lemmy.worldEnglish
    31·
    5 months ago

    If you don’t have any good reason not to, always set your SSH server to only authenticate with keys.

    Anything else is irrelevant.

    • AbidanYre@lemmy.worldEnglish
      162·
      5 months ago

      If you don’t have any good reason not to

      Spoiler alert: you don’t.

      • marcos@lemmy.worldEnglish
        18·
        5 months ago

        This is the internet. If you poke the bear, somebody will come-up with a completely reasonable use case of password authentication that happened once somewhere on the world.

        • Captain Aggravated@sh.itjust.worksEnglish
          2·
          5 months ago

          Playing with a Raspberry Pi inside my own home network with nothing important going on and I turned the Pi off when I’m done. Like why worry about it at that point?

          • Acters@lemmy.worldEnglish
            3·
            5 months ago

            Yes, but I usually add my public key to the authorized_keys file and turn off password authentication once i do login with a password. On top of that, I have a sshpass one line command that takes care of this for me. It’s much easier than trying to manually type a password for the next time. I save it and just run it every time I think about using password login. Next time I need to ssh, I know the password login is not necessary.

            sshpass -p ‘PASSWORD’ ssh USER@IP.ADDRESS “echo ‘`cat ~/.ssh/id_rsa.pub`’ > ~/.ssh/authorized_keys && echo ‘Match User !root
            PasswordAuthentication no
            Match all’ > /etc/ssh/sshd_config’ && exit” && ssh USER@IP.ADDRESS

            At the next reboot, your system will now only accept key logins, except for root. I hope the root user password is secure. I don’t require it for root because if a hacker does gain shell access, a password(or priv esc exploit) is all they need to gain root shell. It is also a safety net in case you need to login and lost your private key.

          • marcos@lemmy.worldEnglish
            21·
            5 months ago

            Yeah, that’s not a good reason.

            It’s much easier to authorize a key than to input your password on every kind of interaction.

        • AbidanYre@lemmy.worldEnglish
          11·
          5 months ago

          If there is, I’d love to hear it. But even JuiceSSH on Android has supported keys for like the last decade.

  • Audalin@lemmy.worldEnglish
    81·
    5 months ago

    Disabling root login and password auth, using a non-standard port and updating regularly works for me for this exact use case.