Responding to idlemind.
Security by obscurity is a term used when you rely on obscurity as your only real form of security. Changing the port is an additional layer of protection to an already hardened service. And as I already mentioned earlier in this thread, it drops attempted attacks down from literally thousands a day to a few a week. SSH is no less secure because the port changed, but it now faces less attacks. There is no rational argument in which that is a bad thing.
Moving it to 21 which is a common port as well only increases the odds.
In my response, which you quote, I say clearly
Running it on a non standard port (I don’t really run it on 21)
It seems you responded without actually reading what I said. While I appreciate all help and suggestions, suggestions based on half read problems have the potential to create more problems than they solve.
If 22 must be available to external users their are better techniques to slow down even a determined attacker. You could use bastion hosts that support more sophisticated controls and only those bastions are allowed to reach the routers SSH port. The additional controls might be additional and stronger algorithm support as well as one more additional factors to authenticate to it, possibly am attach detection and restriction tool like fail2ban. Remove the need to SSH to the outside entirely if possible. Basically there are better methods to harden your SSH service that provide realistic improvements than hoping someone doesn’t find out what port the service runs on.
By bastions I suspect you mean firewall type machines that protect the routerboard from the Internet. Kind of like the two firewalls mentioned in my response, which you quoted. You also read the config I posted earlier and saw that the switch has no public IP addresses, and hence no public facing SSH ports.
There is also, to the best of my knowledge, no official or working fail2ban implementation for RouterOS, and even if there was it would chew up valuable resources needed by a multi-GB switching switch (and as I have stated numerous times, this is PRIMARILY a switch). HOWEVER, changing the port does increase security without softening SSH, and does NOT have any performance impact.
Also as far as I’m aware RouterOS does not support ed25519 but we did get rsa-sha2-256 signature support in response to OpenSSH basically killing rsa-sha at this point. Small victories I suppose.
You are correct, thanks for pointing that out. I will modify the policy allowing an exception for using RSA 8192 keys where ed25519 is not available.
I’d like to stress, again, that I appreciate all the help I can get for resolving my problem. However, this post was tangential and only addressed a problem that wasn’t a problem, and attempted to do so while ignoring most of the salient facts presented, finally suggesting solutions that were already in place.
I’d like to address the idea of changing the SSH port quickly.
On resource constrained devices, changing the SSH port to something above 1024 adds security without creating any security holes, assuming you update any existing security measures that may be available to accommodate the new port. A security plus with no minus.
On machines and devices that are not resource constrained and are able to run arbitrary security enhancing tools, then changing the port to something above 1024 STILL offers some additional protection at no cost (update other tools as needed, of course). A plus with no minus. Additionally, you can then configure your own script, or something like fail2ban to IMMEDIATELY take protective action against any source connecting to port 22 as there is no legitimate reason for doing so. (Someone may do it my mistake, but this will act as a rather effective lesson in being careful what you do when managing an Internet connected server). Another plus with no (real) minus.
The only reason to run SSH on port 22 is if your ISP does some sort of traffic management prioritising port 22 traffic, or if you are unable to change it due to permission or technical limitations.
If you disagree, consider two simple questions:
- If a serious ssh flaw is discovered, who are MORE LIKELY be hit first - those running ssh on port 22, or those running on some other port? Who are MORE LIKELY to have more time to realise there is a problem and mitigate it - those running ssh on port 22, or those running on some other port?
- If your password has been somehow compromised (anonymously) or is weak, when are you MORE LIKELY to be compromised: If your machine gets thousands of hits a day on port 22, or just a few a week on port xxxx?
- When should you take attacks more seriously - when there are thousands of anonymous attacks per day, or when there are a few targeted attacks per week? Which is MORE LIKELY to need attention? Which is MORE LIKELY to even be noticed?
Since SSH is stable and secure, bugs and bad passwords are the only two viable attack vectors and your exposure to both is mitigated by changing your SSH port. So calling a changed SSH port “security by obscurity” is wrong, misleading, and potentially dangerous.
Feel free to disagree, but please motivate your argument if you do so.
