forwarding port 22 safe?

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.

3

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.

3

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

2
- Easy to do with known internal networks.
  
  Difficult to manage when roaming.
  
  1
- Add port knocking, if we go all out, let's go all out!
  
  1
To help with identifying issues within your SSHd configuration, I recommend using ssh-audit: https://github.com/jtesta/ssh-audit

1
Configure lockout to block upon 3 failed attempts

fail2ban

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

1

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

3

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.

3

Likely better behind a VPN. This was reported recently. https://thehackernews.com/2023/11/experts-uncover-passive-method-to.html?m=1

2
- 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.
  
  1
Change your port.

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

1
- 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.
  
  1
Realistically no one is cracking my super long randomized password either. Seems fine to leave it on as backup login.

1
If you really want security you should also add UFW and restrict it to only your IP address.

1
Also don't use rsa, use Ed25519 nowadays

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

No. Just VPN in and SSH in.

2

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

Both accept login.

Both provide can be brute forced / if using password.

3
- WireGuard uses UDP and will not respond if the attacker doesn't have the correct key. So the port used by WG will appears as a closed port.
  
  1
- 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.
  
  1
I think many ppl are missing a step here. Setup a VPN with wireguard or similar. Then in ur sshd configs only allow ssh from ur VPN local subnet. That on top of ssh key login is pretty secure. Unless one of ur other services gets compromised and they pivot to ur VPN network. Then u prob have more problems tbh

1

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

2

Get fail2ban setup at a minimum

2

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

2

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

1

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!

1

Port forwarding will work, but it has major downsides

Will draw attention of bots
Secure as long as there are no security holes in openssh (which is rare but has happened)
You _must_ harden the ssh server by disabling password auth, putting behind fail2ban

There are far better and safer alternatives that I would recommend over exposing a raw port to the world.

Tailscale
Wireguard/OpenVPN

1

The bots are looking anyways.

The other options being presented are various VPNs. OpenSSH has far more eyes on it, for much longer than any of the VPNs. Both generally run as root on the host and so have similar attack surfaces.

Disabling password auth is less important than having good passwords, but is still a good idea since turning off passwords guarantees no bad passwords. Fail2ban provides no security.
1
I would also add twingate as an alternative.

1

Port knocking could be useful here

1

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

1

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.

1

I would risk it. After all, it's the only thing protecting my entire gitlab account. If someone could break my ssh, they could do what they want to my gitlab presence,and I'm guessing someone at gitlab is paid and qualified to make that call.

1

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

1

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.

1

but you still have to expose something to connect to wireguard?

1
- The benefit of wireguard^ is it runs over udp and won't respond unless a peer with the right key hits it. ie a port scan won't reveal anything because there's no tcp port open to handshake, and wireguard won't respond to junk data coming in.
  
  ^ Most VPNs run over udp. But i'm not sure say OpenVPN will respond to random crap, it probably won't but i don't want to state categorically that it won't.
  
  1
- Of course. But it's just another layer to the onion. Pfblockerng, Crowdsec, Fail2Ban, wireguard....layers.
  
  1

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.

1

I have a port 22 ssh process that denies everything, and a separate ssh process on a different port that accepts logins as normal. So someone could obviously find the hidden one, but it won't be the apparently-functional one that they can hit day and night and never get any results from.

1
- Fair enough. If you can run firewall rules then great. But opening up something like ssh to the internet is a risky risk. Cert auth is not a bad way to go in that scenario.
  
  1

With PubKey and Fail2Ban its probably ok but wouldnt chance it personally. Can you use a different port too?

1

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 :)

1

Yes, but you should change the port

1

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

1

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.

1

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

1

Set up free Tailscale and access your server that way.

1

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

1

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.

1

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.

1
Wireguard doesn't answer unless you hand shake with a valid package.

There are three 512 bit keys.

And you can put ssh behind it with ssh keys.

The extra later of defence is quite significant.

No "actual user" is blocked by fail2ban. They auth with keys, can't really fail.

Blocking after three fail is very reasonable and effective. It also keeps the logs noise down.

1

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.

1

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

1

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

1

Why not both?

1
- With a VPN there's no need to change the port. Unless you change all of your ssh ports to another set pretty across all of your hosts, you're just asking for a headache at scale.
  
  1

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

1

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

1

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 👍

1

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.

1

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.

1

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.

1

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.

1

no

1

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.

1

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.

1

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"

1

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

1