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.
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?
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.
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
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.
But then it’s blatantly obvious and you can behavior block.
Apparently, the downvoters don’t understand IPS.
If you disable password authentication, and use public key authentication, yes.
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!!
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
Good summaries. How does the TOTP 2FA article handle drop/reconnects? TOTP needed for each reconnect attempt?
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.
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.
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/
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
I run this on port 22 and ssh with keys on a different port
Get fail2ban setup at a minimum
Better use some kind of VPN and only open the SSH port over the VPN interface.
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
- 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.
I would also add twingate as an alternative.
Is always better to randomize your ssh port, you will be safe from some scans
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.
I recommend implementing a VPN (wireguard is working very well for me) and through that do ssh
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.
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.
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.
I agree entirely. The box I have this on is my piddle-around server. A long time ago I used to administer a medium-sized cluster of Linux boxes and they were all cert auth, and I wouldn’t have had it any other way. Mostly, I think it’s fun to see what usernames and passwords the scripts and bots and hackers try on my neutered SSH.
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.
but you still have to expose something to connect to wireguard?
Of course. But it’s just another layer to the onion. Pfblockerng, Crowdsec, Fail2Ban, wireguard…layers.
but wouldn’t you have to pay a performance penalty running ssh on top of wireguard.
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.
thank you for the explanation.
Move it to a four digit port on your router and port for to 22 internally.
With PubKey and Fail2Ban its probably ok but wouldnt chance it personally. Can you use a different port too?