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

Self-Hosted Main

515 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?

(page 2) 41 comments
sorted by: hot top controversial new old
[–] s3r3ng@alien.top 1 points 11 months ago

First of all don't expose a machine on your LAN unless it is very well locked down especially with respect to ability to access rest of LAN. To simply access home LAN set up home VPN that has the access instead of opening up a port as powerful as ssh. If you open ssh then put it at some other port than the well known 22 and make it accessible by authorized key only. I would further limit where this ssh can be accessed from using firewall rules.

[–] tanjera@alien.top 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 πŸ‘

[–] highedutechsup@alien.top 1 points 11 months ago
[–] JB1712@alien.top 1 points 11 months ago

Should be safe enough to do this but I’ll throw in one potential caveat. Say that you one day somehow need to troubleshoot your ssh server and have to re-enable password authentication. Depending on how many other services you plan to run, it can be easy to suddenly forget you have port 22 exposed on the outside and someone could potentially break in if you use a weak password. This is why I personally host only necessary https content over port 443 to the world. I host anything else so only my wireguard vpn can access it. As for bots hitting port 22 on the outside can be another huge problem. Changing the port can disuade some but remember that the port number is only two bytes in size. A comprehensive port scan only takes a very short amount of time to complete. This, in my humble opinion, creates an extra point of access for you to remember for not that much to gain. That all being said, forwarding key protected ssh is safe enough to do.

[–] speculatrix@alien.top 1 points 11 months ago

I've opened port 22 to specific IPv4 addresses, like my employer's, friends and family.

For any other IPv4 origin, its best to set up a VPN. It's trivial to set up wireguard.

You're probably safe to open port 22 for IPv6, as the address space is unfeasibly large to be scanned, but still, the secops in me doesn't like security by obscurity, so I don't. Also, there's evidence that hackers use things like IPv6 access logs on NTP to find accessible devices to target.

[–] Gabe_Isko@alien.top 1 points 11 months ago

Honestly? Would not recommend it. Probably no one breaking in soon, but there are just constantly tons of botnets portscanning 22 over the whole IP range. You should at least think of switching ports, but I usually recommend at least having a vpn for ssh.

[–] eirsik@alien.top 1 points 11 months ago

SSH exposed with key auth and not password is fine. It is the exact purpose of SSH after all. Also there are milions of web servers out there with exposed SSH because a lot of their users prefer to work with SSH and CLI instead of a web UI. Big hosts such as GoDaddy, BlueHost, Hostgate and so on, all expose their SSH. You don't see their servers crash and burn every week.

[–] betahost@alien.top 1 points 11 months ago

Or use something like Tailscale.com, secure private mesh vpn. No need to expose any ports.

Added feature that comes with it: https://tailscale.com/tailscale-ssh/

It’s also 100% free

[–] Prof-Mmaa@alien.top 1 points 11 months ago

I keep ssh on port 80, multiplexed with usual HTTP traffic thanks to sslh. Basically it's a protocol switchboard what detects what kind of traffic reaches your server and forwards it to appropriate service. It can distinguish between SSH/HTTP/OpenVPN and a few more.

Pros? Security wise probably nothing more that SSH already offers, but port 80 is rarely (if ever) blocked on other networks and having SSH on port that is non-standard and obscured, cuts way down on random attempts to guess the user/password combination.

[–] blackstar2043@alien.top 1 points 11 months ago

This is my current hardened sshd configuration.

ssh/sshd_config: https://pastebin.com/7tH36TdJ

  • Public key authentication and 2fa using oathtool are used to authenticate.
  • Logging in is only possible for members of the 'ssh-user' group.
  • "root" login is disabled through "PermitRootLogin", "DenyGroups", and "DenyUsers".
  • "restricted" has the ability to log in from any host.
  • "user" is limited to using the internal network to log in.
  • 'admin' can only log in when connected via WireGuard.
  • "sftp" may login, but only uses the sftp server. There is no shell available.

pam.d/sshd: https://pastebin.com/eqkisf4F

  • All successful pre-2FA logins will trigger the 'ssh-login-alert', which sends an NTFY alert containing the time, date, user, and host IP.
  • The use of /etc/users.deny prevents root login.
  • The use of /etc/users.allowed permits login by "restricted", "user", "admin" and "sftp".
  • 2FA and ssh-login-alert trigger do not apply to "sftp"
[–] SamSausages@alien.top 1 points 11 months ago

Yes and no.

Yes if you have the resources to monitor and update. Companies have entire teams dedicated to this.

No if you don't have the resources/time to keep up with it regularly.

IMO, no need to take this risk when you have services like Tailscale available today.

[–] marbonmb@alien.top 1 points 11 months ago

I know that some VPN are able to create private networks for devices logged with your account. For exemple nordvpn is able to connect your devices into their "mesh network" and make your devices available through the VPN. I think it's better than exposing a ssh service on Internet, even with a lot of protections!

[–] Ok_Size1748@alien.top 1 points 11 months ago

Port knocking could be useful here

[–] gentooxativa@alien.top 1 points 11 months ago (1 children)

Is always better to randomize your ssh port, you will be safe from some scans

[–] foomatic999@alien.top 1 points 11 months ago

Using a non-standard port for SSH doesn't make it safer but it greatly reduces noise in your logs. If you only use it yourself, change the port.

[–] InevitableArm3462@alien.top 1 points 11 months ago

I recommend implementing a VPN (wireguard is working very well for me) and through that do ssh

[–] mshorey81@alien.top 1 points 11 months ago (5 children)

Most likely it's fine. Though it's not terribly difficult to set up some flavor of VPN so you're not exposing 22 at all outside your network. Personally I use Wireguard.

load more comments (5 replies)
[–] Swanners@alien.top 1 points 11 months ago (3 children)

I would not do this, people port scan all the time and thats an easy one to look for. Try using an at home vpn like openvpn or in the very least change the ssh port to something odd like 6854 or whatever.

load more comments (3 replies)
[–] billiarddaddy@alien.top 1 points 11 months ago

Move it to a four digit port on your router and port for to 22 internally.

load more comments
view more: β€Ή prev next β€Ί