3 ms·

Why not both? Changing the port is so trivially easy and just moves you out of the way of the majority of low-sophistication automated scans.

teddyh 10y ago
(I repeat my comment from 3 years ago¹:) I think nobody argues that it adds security. The problem is that: 1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits. 2. The security it adds is itself bad (sent in cleartext, easily brute-forced) 3. These problems stand against the many drawbacks of this previously discussed (complexity, confusion, etc.). And the final argument: If increased security is what you want, simply increase your key lengths and/or password lengths, and you will get much more than 8×10⁻⁷³ bits of security, without any of the above problems. ① https://news.ycombinator.com/item?id=6617312 https://news.ycombinator.com/item?id=6617312
- TallGuyShort 10y ago
  Did you reply to the right comment? Feels like you might have been addressing a different issue. There's more to security than information theory. Bits of security aside, if you're not listening on port 22 the majority of wide-scale automated scans miss you entirely. If there were some zero day being actively exploited in the wild, admins occasionally having to remember '2222' instead of '22' is pretty a pretty trivial issue and just sidesteps a lot to buy you some time to patch.
  - teddyh 10y ago
    Again I feel the need to repeat myself¹: I am not in a position where I feel I need to worry about remotely exploitable 0-days in my SSH daemon. If you are, then your situation is, I feel, exceptional. That said, perhaps those people should sponsor a project to fix this for real. This could be accomplished by having not one program, but two, one after the other, both with realistic keysizes and security. The password/key to get log in would be then be the combination of two separate keys, one for each program. But what I have described is more or less the same as having a key/password-protected tunnel on top of SSH, so they could just use that. A 0-day in the tunnel/VPN would not allow access through SSH, and a 0-day in SSH would not matter since SSH can’t be accessed directly in the first place. This way, both the tunnel and SSH would need a 0-day at the same time for the security to fail. Like a RAID-1 array. If even this is not sufficiently secure, just increase the number of layers. ① https://news.ycombinator.com/item?id=6619451 https://news.ycombinator.com/item?id=6619451

teddyh 10y ago

(I repeat my comment from 3 years ago¹:) I think nobody argues that it adds security. The problem is that: 1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits. 2. The security it adds is itself bad (sent in cleartext, easily brute-forced) 3. These problems stand against the many drawbacks of this previously discussed (complexity, confusion, etc.). And the final argument: If increased security is what you want, simply increase your key lengths and/or password lengths, and you will get much more than 8×10⁻⁷³ bits of security, without any of the above problems. ① https://news.ycombinator.com/item?id=6617312 https://news.ycombinator.com/item?id=6617312

TallGuyShort 10y ago
Did you reply to the right comment? Feels like you might have been addressing a different issue. There's more to security than information theory. Bits of security aside, if you're not listening on port 22 the majority of wide-scale automated scans miss you entirely. If there were some zero day being actively exploited in the wild, admins occasionally having to remember '2222' instead of '22' is pretty a pretty trivial issue and just sidesteps a lot to buy you some time to patch.
- teddyh 10y ago
  Again I feel the need to repeat myself¹: I am not in a position where I feel I need to worry about remotely exploitable 0-days in my SSH daemon. If you are, then your situation is, I feel, exceptional. That said, perhaps those people should sponsor a project to fix this for real. This could be accomplished by having not one program, but two, one after the other, both with realistic keysizes and security. The password/key to get log in would be then be the combination of two separate keys, one for each program. But what I have described is more or less the same as having a key/password-protected tunnel on top of SSH, so they could just use that. A 0-day in the tunnel/VPN would not allow access through SSH, and a 0-day in SSH would not matter since SSH can’t be accessed directly in the first place. This way, both the tunnel and SSH would need a 0-day at the same time for the security to fail. Like a RAID-1 array. If even this is not sufficiently secure, just increase the number of layers. ① https://news.ycombinator.com/item?id=6619451 https://news.ycombinator.com/item?id=6619451