Earlier quoted context omitted.
Remote user tries to log in. Cannot. Issues (or trojan prompts for) password. It's a game of percentages.
SSH key verification...
Again, percentages. With enough attempts, some will succeed.
171–180 of 186 posts
Earlier quoted context omitted.
Remote user tries to log in. Cannot. Issues (or trojan prompts for) password. It's a game of percentages.
SSH key verification...
Again, percentages. With enough attempts, some will succeed.
Earlier quoted context omitted.
Is it worth mentioning useless uses of cat in this day and age?
I'm pretty fanatical about efficiency, but it's kind of annoying to have to remember where in the argument sequence for a whole bunch of commands the input file goes. Of course once you use the 'cat' trick you then have to remember which comments require '-', '-f -' or something to that effect because whoever programmed them didn't think the primary use case was to work as a filter. Pipes are one of Unix's most usefu…
Earlier quoted context omitted.
I can’t think of any way it could be otherwise, but please, feel free to enlighten us all how a non-standard port number adds any more security than would an additional 16-bit key.
Vastly fewer attacks -> less cognitive load on admins. The logs don't fill up. Technical protection is likely limited, but then, admin attention is also a limited resource.
Earlier quoted context omitted.
SSH key verification...
Server key? Sure, but what's the accept rate on new keys? On short-lived, poorly provisioned, AWS instaances, as just one example. Again, percentages. With enough attempts, some will succeed.
I can only speak for myself, if other people are ignoring warnings, it's their problem.
Earlier quoted context omitted.
You're looking at this the wrong way, because you seem to assume that non-standard ports adds to security the same way the key length does, which is not the case.
I can’t think of any way it could be otherwise, but please, feel free to enlighten us all how a non-standard port number adds any more security than would an additional 16-bit key.
An entirely different effect has been brought up by others already; a non-standard port is enough to evade ~99 % of all automated attacks, therefore you can run at higher log levels and might notice actual attackers earlier.
Earlier quoted context omitted.
Server key? Sure, but what's the accept rate on new keys? On short-lived, poorly provisioned, AWS instaances, as just one example. Again, percentages. With enough attempts, some will succeed.
If it's a new server (like your example) there should be no other user already logged in. If it's not new, then you'll get a warning. And focusing on the "shortlived", so the damage is also shortlived... I can only speak for myself, if other people are ignoring warnings, it's their problem.
I believe that's been adequately addressed.
Earlier quoted context omitted.
Vastly fewer attacks -> less cognitive load on admins. The logs don't fill up. Technical protection is likely limited, but then, admin attention is also a limited resource.
Also means attackers are much easier to spot in the logs. It's also a point of real interest if an attacker took the time to port scan you first in order to detect which port your ssh is on.
Earlier quoted context omitted.
If it's a new server (like your example) there should be no other user already logged in. If it's not new, then you'll get a warning. And focusing on the "shortlived", so the damage is also shortlived... I can only speak for myself, if other people are ignoring warnings, it's their problem.
The original question was: what's the risk, or threat model. I believe that's been adequately addressed.