Live data from Hacker News

What SSH Hacking Attempts Look Like

medium.com

171–180 of 186 posts

Re: What SSH Hacking Attempts Look Like

#171
post #151

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...

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.

Re: What SSH Hacking Attempts Look Like

#172
post #40

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…

s/comments/commands/ sorry.

Re: What SSH Hacking Attempts Look Like

#174
post #139

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.

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.

Re: What SSH Hacking Attempts Look Like

#175
post #151

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.

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.

Re: What SSH Hacking Attempts Look Like

#176
post #139

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.

Non-standard ports, port knocking and similar things work before anything reaches sshd; so they can mitigate vulnerabilities in sshd. Obviously a non-standard port is the weakest fellow in the bunch, but that does not mean the effect is zero. An extra 16 bit key length would obviously never mitigate a sshd vulnerability.

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.

Re: What SSH Hacking Attempts Look Like

#177
post #175

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.

The original question was: what's the risk, or threat model.

I believe that's been adequately addressed.

Re: What SSH Hacking Attempts Look Like

#178

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.

Or, if you prefer, you're choosing to associate with a higher grade of adversary.

Re: What SSH Hacking Attempts Look Like

#180
post #175

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.

The other question is whether other risks are greater; if a high port number is your only choice, or handled by port forwarding on a router, or you are the only user, or high numbers are scanned sufficiently less often, then maybe you still choose one.
Post reply on HN