this post was submitted on 28 Nov 2023
3 points (100.0% liked)

Self-Hosted Main

511 readers
1 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.

For Example

We welcome posts that include suggestions for good self-hosted alternatives to popular online services, how they are better, or how they give back control of your data. Also include hints and tips for less technical readers.

Useful Lists

founded 1 year ago
MODERATORS
 

i want to remotely ssh to my home server, and I was wondering if I could just forward port 22 with disabling password login and use pubkey authentication will be safe enough?

top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 3 points 11 months ago

disabling password login and use pubkey authentication will be safe enough?

Just make sure you actually disable password login. Simply enabling key doesn't disable password. So as long as the password is disabled then you're fine.

[–] [email protected] 3 points 11 months ago (4 children)

Disable password auth.

Enable key only auth.

Add in TOTP 2FA (google authenticator).

Randomize the port (reduce bots) that forwards to 22.

Configure lockout to block upon 3 failed attempts, for a long duration like 1 year. (Have a backup access on LAN).

Ensure only the highest encryption ciphers are accepted.

Ensure upgrades are applied to sshd at least monthly.

[–] [email protected] 2 points 11 months ago (2 children)

If you are going all out, may as well add hosts.deny and hosts.allow.

[–] [email protected] 1 points 11 months ago (1 children)

Easy to do with known internal networks.

Difficult to manage when roaming.

[–] [email protected] 1 points 11 months ago

Absolutely, just sometimes people forget those tools even exist. Of course, you can easily do the same thing with firewall rules as well.

Also, that was a great tidbit about the pam email notification on successful logon. I haven't seen that one before, thank you!!

load more comments (1 replies)
[–] [email protected] 1 points 11 months ago

Good summaries. How does the TOTP 2FA article handle drop/reconnects? TOTP needed for each reconnect attempt?

[–] [email protected] 1 points 11 months ago

To help with identifying issues within your SSHd configuration, I recommend using ssh-audit: https://github.com/jtesta/ssh-audit

load more comments (1 replies)
[–] [email protected] 3 points 11 months ago

If you disable password authentication, and use public key authentication, yes.

[–] [email protected] 3 points 11 months ago (5 children)

As long as password auth is disabled you’re fine. No one is cracking your RSA key. You can add Fail2Ban to reduce the log noise, but security wise it’s fine.

[–] [email protected] 2 points 11 months ago (1 children)
[–] [email protected] 1 points 11 months ago (1 children)

Dont connect it to the internet too. Chances are even less likely that some navy seals kinda guys will steal you data with brute force. Also always keep explosives next to your hdds so once they do come you can explode them.

load more comments (1 replies)
[–] [email protected] 1 points 11 months ago (1 children)

Change your port.

No one's cracking a proper implementation of RSA, but not every implementation is proper. A little obscurity can't hurt.

[–] [email protected] 1 points 11 months ago (1 children)

Just waiting for everyone to come in saying you shouldn’t do this lol. Yes, changing the port is a nice little bonus. It doesn’t any extra security, but it moves you out of the way from the automated bots that scan the internet trying recent 0days. You’ll probably see a reduction of 99% traffic hitting the service and the only logs will be real people.

[–] [email protected] 1 points 11 months ago (2 children)

only logs will be real people.

There are bots that scan for open ports in minutes.

[–] [email protected] 1 points 11 months ago (2 children)

But then it's blatantly obvious and you can behavior block.

[–] [email protected] 1 points 11 months ago

Apparently, the downvoters don't understand IPS.

[–] [email protected] 1 points 11 months ago (1 children)

Which is easily defeated by using one block of ip addresses to gather data and another block for actually trying to exploit found ports. Unless you block the whole AS. If the attacker only uses one system with one ip they probably wouldn’t have the resources to get past ssh anyway.

load more comments (1 replies)
load more comments (1 replies)
[–] [email protected] 1 points 11 months ago (1 children)

Also don't use rsa, use Ed25519 nowadays

[–] [email protected] 1 points 11 months ago (6 children)

RSA is fine. It isn't like you will have to worry about the length of the keys for SSH.

load more comments (6 replies)
[–] [email protected] 1 points 11 months ago

Realistically no one is cracking my super long randomized password either. Seems fine to leave it on as backup login.

load more comments (1 replies)
[–] [email protected] 2 points 11 months ago

I run this on port 22 and ssh with keys on a different port

[–] [email protected] 2 points 11 months ago

Get fail2ban setup at a minimum

[–] [email protected] 2 points 11 months ago (2 children)

No. Just VPN in and SSH in.

[–] [email protected] 3 points 11 months ago (2 children)

How is a VPN service more secure than an SSH service?

Both accept login.

Both provide can be brute forced / if using password.

[–] [email protected] 1 points 11 months ago (1 children)

Generally speaking. VPN is easier to setup securely out of the box for most especially with limited knowledge. You can choose a random port and then have access to any server on your network. Scanners won’t usually test all ports unless they find something that’s tempting.

Normally just the normal ports will be poked including 22. SSH can be secured well but not without jumping through a few hoops. It’s easier imho to accidentally allow access through incorrect ssh setup than vpn.

When you think vpn has been developed with this exact purpose in mind. It’s fair to assume the protection will be better out of the box. If you have a vpn then a hacker needs to get through the vpn and then also the ssh so there’s not really any disadvantage to using a vpn and then also harden ssh if you want to.

It’s about making things difficult. Nobody is going to spend days or weeks battering a vpn if they don’t think there’s anything useful behind it. A VPN also shows somewhat that you’ve given things consideration and are not an easy target.

Don’t get me wrong. If somebody is determined enough and has the resources then they will find a way but given the choice between an easy target and one that’s ever so slightly more difficult, they will almost always go for the easiest.

[–] [email protected] 1 points 11 months ago (1 children)

VPN is easier to setup securely out of the box for most especially with limited knowledge.

One of the top audit companies disagrees with you: https://blog.trailofbits.com/2016/12/12/meet-algo-the-vpn-that-works/

load more comments (1 replies)
load more comments (1 replies)
load more comments (1 replies)
[–] [email protected] 2 points 11 months ago

Better use some kind of VPN and only open the SSH port over the VPN interface.

[–] [email protected] 1 points 11 months ago

A VPN will always be better for this purpose, but as long as you properly secure your SSH server, shouldn't be a problem

[–] [email protected] 1 points 11 months ago

In a word no. That’s not a port you want others sniffing around. Some isps actively block that port for security. IMHO a vpn is the best way. That way you get full access to your network as if you’re using a wired direct connection. You “can” use port 22 and you can make it pretty secure but I just wouldn’t feel safe directly exposing it when there are other ways. Imagine the access somebody could get if you do something slightly wrong or you miss a patch for a new vulnerability. Yep it’s unlikely but why risk it. Put it behind something on a none standard port rather than a port that every sniffer will poke at :)

[–] [email protected] 1 points 11 months ago

Set up free Tailscale and access your server that way.

[–] [email protected] 1 points 11 months ago (1 children)

Rather than port forward 22, I would recommend using the ipv6 address and securing the host.

[–] [email protected] 1 points 11 months ago

ipv6 is great, if not for the fact that many ISPs around the world still haven't bothered rolling it out decades later, making it inaccessible for many.

[–] [email protected] 1 points 11 months ago

In my case, password auth disabled, changed port, fail2ban, and not exposing the port, I connect through vpn and then ssh, but in the end it's still an open port for the vpn

[–] [email protected] 1 points 11 months ago

Yes, it's perfectly safe. Keep it patched, use strong ciphers, use key authentication, and set up an IDS like Fail2Ban or CrowdSec.

[–] [email protected] 1 points 11 months ago (2 children)

A tremendous amount of cargo culting going on here.

As long as your server is aggressively kept up to date and doesn't have any guessable passwords, exposing port 22 can be done safely. If you're not certain about these, you shouldn't. OpenSSH is exposed to the open internet on millions of servers, it's meant to do this.

Fail2ban or changing your ssh port provides no additional security and only serves to reduce log noise at the risk of blocking actual users.

A VPN makes no practical difference. ssh uses strong encryption just like the VPN. Sure you're hiding ssh, but the VPN provides a similar attack surface.

[–] [email protected] 1 points 11 months ago

If you're not certain about these, you shouldn't.

If someone is asking random assholes on the internet if they should do something, I'm guessing the answer to this is no.

load more comments (1 replies)
[–] [email protected] 1 points 11 months ago (3 children)

I wouldn't open up 22 to the world. I would change the port at a minimum or use a VPN.

load more comments (3 replies)
[–] [email protected] 1 points 11 months ago

Using an alternate port will drastically cut down on the number of people trying to brute force your server

[–] [email protected] 1 points 11 months ago

Depending on how you will be connecting depends on how you should configure this. I would strongly suggest just setting up a Wireguard server and connect to it via VPN. At the same time, exposing the port and using a pubkey with Fail2Ban would be the next best option, while always keeping your server patched with port forwarding a different port to the stand SSH port internally.

These are the simplest ways to do this and still be secure. Again, I strongly suggest setting up a private VPN of your choosing.

WireGuard Installs - https://www.wireguard.com/install/

WireGuard Docker - https://github.com/wg-easy/wg-easy

[–] [email protected] 1 points 11 months ago

Port forwarding opens an attack surface- whatever service you're exposing is the "attack surface" so make sure it's secure.

disabling password login

This is absolutely a very strong/good hardening first-step.

pubkey authentication

Hell yeah. Very strong. Just keep that key safe (don't post it on the Internet, put it somewhere insecure or public, etc. Also recommended to password protect the key for extra safety.

Additional steps you could take if you were worried: two-factor authentication, usually easy to setup and effective. Fail2ban or other IP blockers, takes more work and setup. Rate-limiting is a basic feature most ssh services have (e.g. more than 3 failed attempts = 5 minute lockout).

But honestly keys-only, IMHO, is the safest 👍

load more comments
view more: next ›