3 ms·

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 car

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.
  - guiambros 14y ago
    > You can redirect ssh failure messages to a specific log > file, separate from all others That's exactly the point. Now you redirect ssh failure messages to a specific log file (with all the garbage and automated attacks), and you'll very soon start to ignore it. And then your overall security is reduced, simply because you aren't paying attention. Or, you can spend time combing through hundreds of invalid messages, trying to separate the wheat from the chaff. Either in one or multiple separate files, it doesn't really matter. Anyway, not trying to convince anybody here. I respect the opinion that some may prefer to leave everything as the default. For me, I just vehemently disagree with OP's point that using a non-std port doesn't have concrete benefits and/or reduce the security. To me it's exactly the opposite. At least if you know what (and why) you're doing.

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.
- guiambros 14y ago
  > You can redirect ssh failure messages to a specific log > file, separate from all others That's exactly the point. Now you redirect ssh failure messages to a specific log file (with all the garbage and automated attacks), and you'll very soon start to ignore it. And then your overall security is reduced, simply because you aren't paying attention. Or, you can spend time combing through hundreds of invalid messages, trying to separate the wheat from the chaff. Either in one or multiple separate files, it doesn't really matter. Anyway, not trying to convince anybody here. I respect the opinion that some may prefer to leave everything as the default. For me, I just vehemently disagree with OP's point that using a non-std port doesn't have concrete benefits and/or reduce the security. To me it's exactly the opposite. At least if you know what (and why) you're doing.