4 ms·

While I'm not sure if you can argue 'no protection' while at the same time admitting that the number of attacks was greatly reduced for a while: I always hated

While I'm not sure if you can argue 'no protection' while at the same time admitting that the number of attacks was greatly reduced for a while: I always hated that advice with a passion. No, do not run SSH on a non-default port. It's nothing but an obscurity hack, does little good and breaks a lot of workflows (routers that prioritize port 22 as interactive traffic, firewalls that explicitly allow ssh - on port 22 of course, tools that are awkward to use as soon as you need to use a different port than the _standard_ one). I admit that I mocked people recommending that practice in the past. That's childish of course, but if the data of this submission is correct I can now add a more serious 'Please do not do that' argument to my list.

pekk 14y ago
It is my host. I don't need all the log noise. I am taking the same standard precautions on the higher port that one is supposed to take with the default port. Why should I care about your workflows over mine?
- darklajid 14y ago
  You shouldn't. If I did imply that, please point out where. I certainly didn't to make that impression. I just doubt that a change of port makes sense, I don't claim that it's a amoral or anything. You do it? Yeah, go ahead. Please don't recommend it as 'best practice' is all that I ask for, with both the argument and my condensed workflow examples listing scenarios why this might not be useful.
guiambros 14y ago
There's a strong reason for advocates (like myself) for running ssh on non-standard ports: it reduces 99% of automated attacks and bots. Yes, you could use fail2ban and ban half the internet, but that just clogs your filtering rules and makes your system waste memory and cycles. Case in point: one of my servers with ssh on port 22 had +9,000 denied IPs over less than one year. On a non-std port, ~100. There's almost no drawback to using a non-standard port. Everything that uses ssh allow port customization (and I wouldn't trust something that doesn't). > routers that prioritize port 22 as interactive traffic Internet routers don't typically do any QoS (except to reduce the priority - bittorrent/etc), let alone prioritize 22. And within your own network, you have control over QoS anyway. Also, I disagree with the OP: >...those who have moved their main login service to a non-standard port pay less attention to their logs than the rest of us I believe it's exactly the opposite. When you're used to carefully inspect your logs on an ongoing basis, you don't want to see it polluted by automated attacks. Now when you use a non-std port and discover people doing port scans, you'd better pay attention...
- darklajid 14y ago
  Thanks for the elaborate answer. My take: If the fail2ban solution bans 9000 IPs - why would you care? If password authentication is disabled (is it?), who cares? What's _gained_ here, except for a potentially smaller log file? Everything that uses ssh allow port customization (and I wouldn't trust something that doesn't). Sure. I agree. The problem starts, if you mix a lot of clients. Say, I'm using two different OS' (Windows, Linux). For Windows that means putty for me (one interface) or WinSCP (two interfaces to manage). On Linux I'm using ssh (ssh foo@host:port) or scp (scp -P port ..). I certainly CAN manage .ssh/config files and reduce that mental overhead a bit. But my argument is that this makes no sense. It - in my world - doesn't buy you security, but might cause mental laps and cache misses that annoy you. So, I still fail to see a reason to do that..
  - guiambros 14y ago
    > What's _gained_ here, except for a potentially smaller log file? - Smaller and easier to parse log files - Less time wasted parsing log files (or creating scripts to filter out automated attacks) - Less RAM & CPU cycles (particularly important when running low memory VMs) I still fail to see a reason to NOT do that. It won't increase your overall security, but it doesn't reduce it either, so why not do it? Just to save you from adding 'alias ssh=ssh -P xx' to your .profile?
    - icebraining 14y ago
      Just to save you from adding 'alias ssh=ssh -P xx' to your .profile? Or better yet, add it to your .ssh/config file: Host myhost Hostname myhost.com Port xxxx This way, it doesn't conflict with other hosts.
    - viraptor 14y ago
      You can redirect ssh failure messages to a specific log file, separate from all others, so that shouldn't be an issue. Also you don't need to alias - .ssh/config should work more transparently here.

pekk 14y ago

It is my host. I don't need all the log noise. I am taking the same standard precautions on the higher port that one is supposed to take with the default port. Why should I care about your workflows over mine?

darklajid 14y ago
You shouldn't. If I did imply that, please point out where. I certainly didn't to make that impression. I just doubt that a change of port makes sense, I don't claim that it's a amoral or anything. You do it? Yeah, go ahead. Please don't recommend it as 'best practice' is all that I ask for, with both the argument and my condensed workflow examples listing scenarios why this might not be useful.

guiambros 14y ago

There's a strong reason for advocates (like myself) for running ssh on non-standard ports: it reduces 99% of automated attacks and bots. Yes, you could use fail2ban and ban half the internet, but that just clogs your filtering rules and makes your system waste memory and cycles. Case in point: one of my servers with ssh on port 22 had +9,000 denied IPs over less than one year. On a non-std port, ~100. There's almost no drawback to using a non-standard port. Everything that uses ssh allow port customization (and I wouldn't trust something that doesn't). > routers that prioritize port 22 as interactive traffic Internet routers don't typically do any QoS (except to reduce the priority - bittorrent/etc), let alone prioritize 22. And within your own network, you have control over QoS anyway. Also, I disagree with the OP: >...those who have moved their main login service to a non-standard port pay less attention to their logs than the rest of us I believe it's exactly the opposite. When you're used to carefully inspect your logs on an ongoing basis, you don't want to see it polluted by automated attacks. Now when you use a non-std port and discover people doing port scans, you'd better pay attention...

darklajid 14y ago
Thanks for the elaborate answer. My take: If the fail2ban solution bans 9000 IPs - why would you care? If password authentication is disabled (is it?), who cares? What's _gained_ here, except for a potentially smaller log file? Everything that uses ssh allow port customization (and I wouldn't trust something that doesn't). Sure. I agree. The problem starts, if you mix a lot of clients. Say, I'm using two different OS' (Windows, Linux). For Windows that means putty for me (one interface) or WinSCP (two interfaces to manage). On Linux I'm using ssh (ssh foo@host:port) or scp (scp -P port ..). I certainly CAN manage .ssh/config files and reduce that mental overhead a bit. But my argument is that this makes no sense. It - in my world - doesn't buy you security, but might cause mental laps and cache misses that annoy you. So, I still fail to see a reason to do that..
- guiambros 14y ago
  > What's _gained_ here, except for a potentially smaller log file? - Smaller and easier to parse log files - Less time wasted parsing log files (or creating scripts to filter out automated attacks) - Less RAM & CPU cycles (particularly important when running low memory VMs) I still fail to see a reason to NOT do that. It won't increase your overall security, but it doesn't reduce it either, so why not do it? Just to save you from adding 'alias ssh=ssh -P xx' to your .profile?
  - icebraining 14y ago
    Just to save you from adding 'alias ssh=ssh -P xx' to your .profile? Or better yet, add it to your .ssh/config file: Host myhost Hostname myhost.com Port xxxx This way, it doesn't conflict with other hosts.
  - viraptor 14y ago
    You can redirect ssh failure messages to a specific log file, separate from all others, so that shouldn't be an issue. Also you don't need to alias - .ssh/config should work more transparently here.