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
    21·
    1 year 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.

    • The Bard in Green@lemmy.starlightkel.xyzEnglish
      3·
      1 year ago

      Easy. I have servers that are only available on my local network and lots of different devices that I MIGHT want to use to access those servers. I haven’t bothered to make sure my key is on EVERY SINGLE DEVICE and some of them, I might not actually even WANT my key on as they’re not terribly well secured and they might leave my house (my Windows gaming laptop I haven’t used in six months comes to mind).

      But for cloud accessible servers… yeah.

      • EarMaster@lemmy.worldEnglish
        2·
        1 year ago

        You know you’re allowed (some might even say supposed) to have different keys for different machines. They’re basically free to generate and take up to no space.

    • Captain Aggravated@sh.itjust.worksEnglish
      2·
      1 year 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·
        1 year 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·
        1 year 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·
      1 year ago

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