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?
You must log in or register to comment.
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.
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.
If you are going all out, may as well add hosts.deny and hosts.allow.
Add port knocking, if we go all out, let’s go all out!
Easy to do with known internal networks.
Difficult to manage when roaming.
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!!
Good summaries. How does the TOTP 2FA article handle drop/reconnects? TOTP needed for each reconnect attempt?
To help with identifying issues within your SSHd configuration, I recommend using ssh-audit: https://github.com/jtesta/ssh-audit
Configure lockout to block upon 3 failed attempts
fail2ban
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.
Likely better behind a VPN. This was reported recently. https://thehackernews.com/2023/11/experts-uncover-passive-method-to.html?m=1
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.
Thats why I store thermite by my rack. Burns it all down.
Also don’t use rsa, use Ed25519 nowadays
RSA is fine. It isn’t like you will have to worry about the length of the keys for SSH.
Requires an actual hardware error. Almost all implementations, including all open source SSH implementations, check that the signature is valid thus preventing a cosmic ray induced bit flip from triggering this issue and any related issue.
What effect do hardware errors have on Ed25519?
Well it‘s true that one can use RSA, which is still save with keys big enough, but if someone wants so save some extra computing power and time ed25519 is the way to go.
The difference is extremely tiny because asymmetric encryption is only used at the very beginning to securely establish a symmetric key that will be used for everything else afterwards. So you would have to be running this on a smart fridge to notice the speed difference.
True enough
It is but if you’re going to use something security related, use the current recommendation unless you stricly can’t for legacy reason or something.
If you really want security you should also add UFW and restrict it to only your IP address.
Realistically no one is cracking my super long randomized password either. Seems fine to leave it on as backup login.
Change your port.
No one’s cracking a proper implementation of RSA, but not every implementation is proper. A little obscurity can’t hurt.
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.
only logs will be real people.
There are bots that scan for open ports in minutes.
Yes but most bots are scanning for common ports. It’s far too slow to scan 65k ports on every host. Even things like shodan only scan a handful of common ports. But you can test this yourself, expose SSH on a port number in 20-40ks, I’ve seen several weeks without a single probe.
If you’ve ever done mass scanning you know that’s minutes is not going to to be a full scan and if you are trying to do 65k ports in a few minutes, your results will not be accurate.
But then it’s blatantly obvious and you can behavior block.
Apparently, the downvoters don’t understand IPS.
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.
Behavior blocking can be done across many IPs.
If you have one IP that scans port 10000, the other port 10001, and thousands of other IPs scanning just 1 port it’s still blatantly obvious.
And if they want to scan in a less obvious manner they need to do this spaced by days.
If you disable password authentication, and use public key authentication, yes.
I run this on port 22 and ssh with keys on a different port
Get fail2ban setup at a minimum
No. Just VPN in and SSH in.
How is a VPN service more secure than an SSH service?
Both accept login.
Both provide can be brute forced / if using password.
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.
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.
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/
A “top” audit company pushing their own agenda.
OpenVPN is simple and easy to deploy on any major operating system. Pfsense or similar is easy to setup and run in a VM. That does all the hard work for you and creates a profile. Then you essentially copy or download that profile to the client machine and you’re done. It’s all done via gui or web interface so is easier for a lot of people. My sister managed it. She wouldn’t have been able to handle command line stuff.
Like i said before though. Why not use a vpn and also harden your ssh. I can’t see a downside to that.
It’s just my opinion and experience from working with both. You’re welcome to dissagree and do your own thing though of course :)
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
Better use some kind of VPN and only open the SSH port over the VPN interface.
Yes, it’s perfectly safe. Keep it patched, use strong ciphers, use key authentication, and set up an IDS like Fail2Ban or CrowdSec.
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.
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.
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.
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.
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.
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.
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
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.