Do I Need to Harden SSH over Tor?
from anon2963@infosec.pub to selfhosted@lemmy.world on 10 Apr 2024 20:15
https://infosec.pub/post/10909581

cross-posted from: 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.

#selfhosted

threaded - newest

marcos@lemmy.world on 10 Apr 2024 22:08 next collapse

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.world on 10 Apr 2024 23:48 collapse

If you don’t have any good reason not to

Spoiler alert: you don’t.

marcos@lemmy.world on 11 Apr 2024 01:34 next collapse

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.works on 11 Apr 2024 05:08 next collapse

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.world on 11 Apr 2024 08:56 next collapse

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.world on 11 Apr 2024 12:30 collapse

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.world on 11 Apr 2024 11:06 next collapse

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

thebardingreen@lemmy.starlightkel.xyz on 12 Apr 2024 03:43 collapse

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.world on 12 Apr 2024 05:29 collapse

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.

lud@lemm.ee on 12 Apr 2024 06:55 collapse

I use a different key for every device I need to connect to.

So my phone has separate keys for each SSH server and so does my desktop and laptop.

It’s not the most convenient thing in the world but it’s not too bad.

Most of the keys are without passphrase but the keys I use to connect to my VPS for example absolutely have a passphrase.

someonesmall@lemmy.ml on 11 Apr 2024 04:22 collapse

30 character password + fail2ban after one failed attempt. Why not?

wreckedcarzz@lemmy.world on 11 Apr 2024 10:58 next collapse

30 character

You’ve gotta pump those numbers, those are rookie numbers. (I have a vps that has several times that figure)

someonesmall@lemmy.ml on 11 Apr 2024 11:49 collapse

Did you read my message? After one failed attempt you will get banned.

wreckedcarzz@lemmy.world on 11 Apr 2024 20:27 collapse

But

30 characters

:P

AbidanYre@lemmy.world on 11 Apr 2024 11:06 collapse

WCGW?

someonesmall@lemmy.ml on 11 Apr 2024 11:49 collapse

Tell me

chaospatterns@lemmy.world on 11 Apr 2024 16:45 collapse

Accidentally typo your password and get blocked. And if you’re tunneling over tor, you’ve blocked 127.0.0.1 which means now nobody can login.

someonesmall@lemmy.ml on 11 Apr 2024 18:01 collapse

How would is a typo possible if one is using a password manager?

baatliwala@lemmy.world on 11 Apr 2024 18:26 collapse

Not OP but I’ve accidentally fingered another key a split second before hitting enter a few times. It’s not implausible.

someonesmall@lemmy.ml on 12 Apr 2024 03:24 collapse

True, but I thought we are talking about security here…?

theRealBassist@lemmy.world on 12 Apr 2024 21:15 collapse

A secure but inaccessible server is useless.

Security must take into account the needs of the real world.

Audalin@lemmy.world on 10 Apr 2024 22:44 next collapse

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

tal@lemmy.today on 10 Apr 2024 23:24 collapse

using a non-standard port

It’s really not that hard to find SSH servers running on a non-standard port.

nmap or a similar port-scanning software package can find ports listening for TCP connections. There are software packages – don’t recall names off-the-cuff, but I’m sure that you could go dig one up – that connect to ports and then aim to identify the protocol from a fingerprint out of a database that they have. The SSH protocol has a very readily-identifiable fingerprint, don’t even need specialized software.

Let me just bounce to a machine as an example:

$ telnet tals-host.tals-domain.com 22
Trying tals-IP...
Connected to tals-host.tals-domain.com
Escape character is '^]'.
SSH-2.0-OpenSSH_9.6p1 Debian-4
^]
telnet> q
Connection closed.
$

That being said, I don’t disagree with your broader point that I wouldn’t personally bother with trying to add more layers on top of ssh, as long as you’re keeping current on updates.

Getting6409@lemm.ee on 11 Apr 2024 07:53 collapse

I feel like the argument for using a nonstandard ssh port these days is that you dodge the low tier automation/bots that are endlessly scanning IPs and port 22 and trying obvious usernames and passwords. I do also question how much it is worth dodging these since presumably you’d have already done the other basics like key only and no root login before this. Maybe there’s some value if you want a clean auth.log or equivalent

tal@lemmy.today on 10 Apr 2024 23:14 next collapse

I think that SSH, hidden or no, is fine. It’s intended to be Internet-facing and secure.

All that being said, we did just infamously have the Jia Tan/xz attack, an attempt to stick a backdoor spanning many Linux distros.

Also, I would treat the public hostname like any other secret, as only I need access to it.

If you’re worried about someone malicious having access to your network connection, ssh is going to do a DNS lookup to map the hostname to an IP for the client.

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.

If you’re going to be running multiple layers of software, keep in mind that compromising the outer layer – whether it’s a port-knocking system, a VPN like Wireguard, some sort of intrusion detection system that inspects packets prior to them hitting the rest of the system, etc – can be equivalent to compromising the inner. And attackers have aimed to exploit things like buffer overflows in IDSes before – this is a real thing. So if, for example, there is a Wireguard exploit, it may permit the same sort of compromise that a compromise of sshd does if gaining control of the Wireguard software is as severe as gaining control of the sshd software. So if you’re wanting to add another layer and your goal is that compromise of the first layer still leaves another layer to get through, you may want to structure things such that compromise of the VPN software doesn’t compromise anything further.

anon2963@infosec.pub on 11 Apr 2024 02:38 collapse

Thanks for the wise words. However I have some questions:

If you’re worried about someone malicious having access to your network connection, ssh is going to do a DNS lookup to map the hostname to an IP for the client.

Are you sure that this is true for Tor? .onion addresses never resolve to an IP address, even for the end user client. If I was on an untrusted network, both for the client and the server, the attacker could find out that I was using Tor, but not know literally anything more than that.

And attackers have aimed to exploit things like buffer overflows in IDSes before – this is a real thing.

I would expect an IDS to be an order of magnitude larger attack surface than Wireguard, and significantly less tested. Although I could also say that about SSH, and we had the recent backdoor. However, I think it is a lot more likely that a bug will cause a security method to be ineffective than actively turn it in to a method for exfiltration or remote access though. For example, with the recent SSH backdoor, if those servers had protected SSH behind Wireguard then they would have been safe even if SSH was compromised.

Decronym@lemmy.decronym.xyz on 10 Apr 2024 23:55 next collapse

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

Fewer Letters More Letters
DNS Domain Name Service/System
IP Internet Protocol
SSH Secure Shell for remote terminal access
TCP Transmission Control Protocol, most often over IP
VPN Virtual Private Network
VPS Virtual Private Server (opposed to shared hosting)

6 acronyms in this thread; the most compressed thread commented on today has 10 acronyms.

[Thread #671 for this sub, first seen 10th Apr 2024, 23:55] [FAQ] [Full list] [Contact] [Source code]

dotslashme@infosec.pub on 11 Apr 2024 16:08 collapse

There are several things you can and should do to harden your server, many of them can be found here.