this post was submitted on 03 Oct 2025
109 points (98.2% liked)

Selfhosted

52107 readers
854 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

Some services run really good behind a reverse proxy on 443, but some others can really become an hassle.. And sometimes just opening other ports would be easier than to try configuring everything to work through 443.

An example that comes to my mind is SSH, yeah you can use SSLH to forward requests coming from 443 to 22, but it's so much easier to just leave 22 open..

Now, for SSH, if you have certificate authentication or a strong password, I think you can feel quite safe, but what about other random ports? What risks I'm exposing my server to if I open some of them when needed for a service? Is the effort of trying to pass everything through 443/80 worth it?

(page 2) 17 comments
sorted by: hot top controversial new old
[–] possiblylinux127@lemmy.zip 11 points 1 week ago (1 children)

With SSH it is easier to do key authentication. Certificate authentication is supported but it is a little more hassle. Don't use password authentication as it is deprecated and not secure.

The key with SSH (openssh specifically) is that it is heavily audited so it is unlikely to have any issues. The problem is when you start exposing self hosted services with lots of attack surface. You need to be very careful when exposing services as web services are very hard to secure and can be the source of a compromise that you may or may not be aware of.

It is much safer to use a overlay VPN or some other frontend for authentication like mTLS or an authenticated reverse proxy.

[–] cmnybo@discuss.tchncs.de 7 points 1 week ago (1 children)

Be sure to keep everything up to date too. Even openssh has had multiple vulnerabilities just this year.

[–] possiblylinux127@lemmy.zip 1 points 1 week ago* (last edited 1 week ago) (2 children)

Always good advise

However, OpenSSH is pretty solid security wise. https://www.openssh.com/security.html

Note: it is best to check the official security pages instead of random websites.

[–] ryannathans@aussie.zone 5 points 1 week ago* (last edited 1 week ago)

Vendors packaging OpenSSH open up even more vulnerabilities that the devs of OpenSSH can't protect you from. See the recent xz poisoned OpenSSH packages

load more comments (1 replies)
[–] abs_mess@lemmy.blahaj.zone 4 points 1 week ago (1 children)

Not a sysadmin, just a casual IT.

If it is open, it is going to get hit by scanners, scrapers, everything and the sun, even if it is secure. Generally, 443 for your websites via reverse proxy with an IP whitelist + password is okay. Not special, lets you add subdomains, very convenient.

Now, there isn't anything special about any given port, but you still need to have some form of access control that you need to set up. If it is an API have some sort of API key in place. Implement 2FA. Try to isolate the service from the machine. Isolate the machine from bare metal. Keep the bare metal machine isolated from your home network. Take up farming. Change the default port and add some form of access alerts/logs. Have some sort of fail2ban service in place because you will be firehosed with scripts and bad traffic.

Maybe some of the stuff I recommend is paranoid overkill, but I don't know enough to cut corners. Security is a hassle, a breach is a nightmare.

[–] possiblylinux127@lemmy.zip 3 points 1 week ago (1 children)

IP whitelists are not terribly secure and are quite a hassle.

Instead use a overlay VPN or some sort of extra security layer like mTLS or Authelia

load more comments (1 replies)
[–] non_burglar@lemmy.world 1 points 1 week ago (1 children)

Presuming you have not limited edge port 22 to one or two IPS and that you are not translating a high port to 22 internal, the danger is that you are allowing the entire internet to hammer away at your ssh. If you have this described setup, you will most definitely see the evidence of attempts to break in in your SSH endpoint and firewall logs.

Zero days for SSH do exist, so it's just a matter of time before you're compromised if you leave this open.

[–] possiblylinux127@lemmy.zip 4 points 1 week ago* (last edited 1 week ago) (1 children)

This is security theater

Flaws in SSH do happen but they are very rare. The solution to this is defense in depth which is different than security by obscurity.

load more comments (1 replies)
[–] 01189998819991197253@infosec.pub -2 points 1 week ago (2 children)

Imagine opening all the windows in your flat. Then leaving them open for a month. What would happen? How many insects would make their new home in your home? How many critters and cats would do the same?

Now, each window is a port. Your flat is your network. Each critter or cat is a bad actor. Each insect is a bot or virus.

[–] possiblylinux127@lemmy.zip 4 points 1 week ago

To expand on this a bit:

A lot of attacks are automated since the goal is to compromise as many hosts as possible. These hosts are then used in a botnet or sold to people on shader websites to use as proxies.

load more comments (1 replies)
load more comments
view more: ‹ prev next ›