Live data from Hacker News

What SSH Hacking Attempts Look Like

medium.com

141–150 of 186 posts

Re: What SSH Hacking Attempts Look Like

#141
post #78

One thing I've found amusing is you can cut down SSH hacking attempts to almost zero (at the cost of compatibility with legacy systems) by using very progressive encryption. If you force use of ChaCha20/Poly1305, ED25519 and so forth in sshd_config, you'll see these attempts almost disappear. There's probably an observation to be made about just how overwhelmingly many of these attempts come from fairly old software…

Or the ratio of script kiddies to developers.

Re: What SSH Hacking Attempts Look Like

#142
post #95

Earlier quoted context omitted.

What is the problem?

Another authorized user or a non-root RCE compromise could start listening on the ssh port if sshd ever dies for some reason.

And then what? /etc/ssh is still owned by root, another user can't see the hostkeys. So you'll get an error message if custom keys are used.

Re: What SSH Hacking Attempts Look Like

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

There is no added security. Just added comfort of not having to deal with spammers filling up logs.

Re: What SSH Hacking Attempts Look Like

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

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.

Re: What SSH Hacking Attempts Look Like

#145
post #135
post #94

Earlier quoted context omitted.

Seeing that you need to press enter, the arrow keys are not far away. I doubt the later one.

You doubt that they keyboards lacked arrow keys? Just look at an ASR-33 (teletype) keyboard or ADM3A. The latter had arrows printed on the hjkl keys but there was no special way to generate “arrow” key presses — those terminals sent 7-bit ASCII characters directly. Look at what # and @ do in cooked mode — THAT goes back to Multics. The teletype was a printing terminal and the ADM3A was a “glass teletype” — essentiall…

No. I doubt that many used them to program shells. Bash is from 1989 for example.

Re: What SSH Hacking Attempts Look Like

#146
post #142

Earlier quoted context omitted.

Another authorized user or a non-root RCE compromise could start listening on the ssh port if sshd ever dies for some reason.

And then what? /etc/ssh is still owned by root, another user can't see the hostkeys. So you'll get an error message if custom keys are used.

Remote user tries to log in. Cannot. Issues (or trojan prompts for) password.

It's a game of percentages.

Re: What SSH Hacking Attempts Look Like

#147

Earlier quoted context omitted.

Changing the port away from 22 also had that effect in my experience.

This was like night and day. Non stop constant barrages on the default port, all quiet on the ssh k@ip -p XXX.

I found that setting the port and user in ~/.ssh/config made everything way easier. Also fill in the IP as HostName if you're not using DNS names.

Re: What SSH Hacking Attempts Look Like

#149
post #116
post #18

Earlier quoted context omitted.

A port knock is just a clear password :/ I much prefer restricting port 22 to a few ip and disable passwords

"A port knock is just a clear password" It is only clear to the routers in your traceroute ... third party attackers cannot snoop on this traffic.

Right, exactly like a clear text password.

Re: What SSH Hacking Attempts Look Like

#150
post #145
post #135

Earlier quoted context omitted.

You doubt that they keyboards lacked arrow keys? Just look at an ASR-33 (teletype) keyboard or ADM3A. The latter had arrows printed on the hjkl keys but there was no special way to generate “arrow” key presses — those terminals sent 7-bit ASCII characters directly. Look at what # and @ do in cooked mode — THAT goes back to Multics. The teletype was a printing terminal and the ADM3A was a “glass teletype” — essentiall…

No. I doubt that many used them to program shells. Bash is from 1989 for example.

I'm not trying to argue; there are not "arrow" characters in the ASCII character set. sh, csh ksh and bash were all developed on ascii terminals. Brian had an Ann Arbor Ambassador which does do 8-bit ASCII but we always had them configured to set the top bit as a "meta" key, so essentially you had 7-bit ascii as well. All these terminals were connected by serial lines to computers (an unusued Vax 750 in the case of the GNU project; that was the machine he developed Bash on -- for the other shells, developed at Bell labs, ksh was also developed also ib a vax while sh and csh were developed on PDP-11s IMHO). You can see the key layouts available back in the days of ASCII terminals here: http://xahlee.info/kbd/vt100_terminal.html and of course use man ascii.

FWIW anyway Brian wouldn't have thought about those keys as the intended use of Readline would have been emacs keystrokes (emacs, or EMACS as it was in those days, had recently been ported to Unix by RMS).

Interestingly our 36-bit machines (PDP-10s and lispms) had arrow glyphs on their custom non-ASCII keyboards (KTV and space cadet) but they were for mathematical notation, not cursor movement!

Post reply on HN