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.
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
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?
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.
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.
Apparently, the downvoters don’t understand IPS.
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.
If you disable password authentication, and use public key authentication, yes.
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
I run this on port 22 and ssh with keys on a different port
Better use some kind of VPN and only open the SSH port over the VPN interface.
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
no
I wouldn’t open up 22 to the world. I would change the port at a minimum or use a VPN.
Why not both?
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.
I have a “prep script” that takes care of everything.
It takes less than 2 minutes to run on a fresh install and does all kind of fun things.
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.
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”
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
Using an alternate port will drastically cut down on the number of people trying to brute force your server
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
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.