"26C.Z969" <26C.Z969@noaada.net> writes:
> On 12/19/22 5:05 AM, Richard Kettlewell wrote:
>> "26C.Z969" <26C.Z969@noaada.net> writes:
>>> On 12/18/22 7:02 AM, The Natural Philosopher wrote:
>>>> He just likes 'new shiny thing, make everything better'
>>>> Creeping featurism as a substitute for genuine progress.
>>>
>>> Ain't gonna be any "genuine progress" using todays
>>> SSH.
>>>
>>> All I did here was ASK A QUESTION ... "Is SSH good
>>> enough anymore ?".
>> Well, no, you said it needed to be replaced with something else,
>
> I suggested that as the "cleanest" option - not like I'm in a position
> to DEMAND anything. And no, I'm not the guy to spend the next five
> years writing a replacement .......

It’s a ridiculous option, given your apparent requirements. Nothing
about the SSH protocol stops you treating scans/probes in any way you
like. Replacing it would be a large amount of pointless work unrelated
to your goals, and sacrifice the interoperability we currently have with
SSH.

>> but then completely failed to explain what that something else would
>> do any differently. At most you’ve made some vague statements about
>> using AI but nowhere explained why feeding information about failed
>> logins into a statistical model would need a new secure remote login
>> protocol. You could do it perfectly well with the log tailing
>> strategy that fail2ban and its workalikes use.
>
> I explained what I saw as weaknesses quite well, IMHO.

The quality of your explanation is measured by how well the audience
understand it, not your opinion.

> And the standard answer was "Hook more external utilities
> to it", which equals A MESS.
>
> How about something you DON'T have to hook lots of
> external utilities into ?

You (or someone) can write an SSH server with any feature set you like,
if time and effort are available, and people do. Some start from OpenSSH
and other start from scratch. But that’s not replacing SSH as you asked
for, that’s just a new server; you’ve said nothing that explains why SSH
is the problem you care about rather than any particular server
implementation. (If there’s really something you don’t like about the
SSH protocol then an RFC reference would make it clearer.)

But since the scanning we’re talking about happens with many other
protocols (e.g. HTTP, IMAP, SMTP) it’d be a bizarre choice to build your
scanner management tools into the server implementation; it prevents
re-use of the work in related contexts. As we’ve already discussed, a
common thing to do is share address reputation information (with DNSBLs
etc) and to do that, you’re definitely going to have external
interfaces, whether you like them or not.

The tight integration you’re asking for also makes it harder for the
different concerns to evolve independently. ECDHC key exchange and
statistical models of attacker behavior are rather different domains and
there’s no inherent reason the people who are good at each should have
to be brought into the same project, work to the same timelines, etc.

> The other angle was in *detecting* attacks and doing smart things if
> those are found. HUMANS can spot them pretty damned easily just by
> looking at a log file or two - but not PCs. "AI" pattern-detection
> seems to be the modern answer.

If you want to do that then nothing about SSH or its implementations is
stopping you. Maybe the lack of an AI model that does what you want is
stopping you or maybe just your own arbitrary constraint about not using
a component model is stopping you, but replacing SSH won’t get you any
closer to your goal.

--
https://www.greenend.org.uk/rjk/

On 12/17/22 10:30 AM, David W. Hodgins wrote:
> On Sat, 17 Dec 2022 03:47:12 -0500, Andreas Kohlbach <ank@spamfence.net>
> wrote:
>
>> On Sat, 17 Dec 2022 02:03:27 -0500, David W. Hodgins wrote:
>>>
>>> On Fri, 16 Dec 2022 21:24:46 -0500, Andreas Kohlbach
>>> <ank@spamfence.net> wrote:
>>>
>>>> On Fri, 16 Dec 2022 10:30:17 +0100, Carlos E. R. wrote:
>>>>>
>>>> Nah, don't. Have them have their fun. They don't know root won't get in
>>>> and waste their own resources. Although today it won't matter
>>>> either. But
>>>> not letting them know they cannot login as root they keep trying
>>>> instead
>>>> of wandering off and try other servers where they might be successful.
>>>>
>>>>> That's something a human operator would do.
>>>>
>>>> I don't think so. Unless being DDoSed. But then you have to take a
>>>> completely different approach to mitigate the traffic.
>>>
>>> I don't block, but I use a non-standard port. Otherwise failed attempts
>>> can fill the filesystem where the logs are stored. I had that happen
>>> before
>>> I switched ports.
>>
>> There's logrotate to take care of logfile sizes.
>>
>> ~$ ls -lrt /var/log/auth*
>> -rw-r----- 1 root adm  78358 Nov 19 23:39 /var/log/auth.log.4.gz
>> -rw-r----- 1 root adm  83875 Nov 26 23:57 /var/log/auth.log.3.gz
>> -rw-r----- 1 root adm  44726 Dec  3 23:46 /var/log/auth.log.2.gz
>> -rw-r----- 1 root adm 449644 Dec 10 23:51 /var/log/auth.log.1
>> -rw-r----- 1 root adm 987377 Dec 17 03:45 /var/log/auth.log
>
> When you get a few dozen hits per minute, it doesn't take a week to use
> a lot
> of log space. Rotating more often will mean info will be removed sooner
> too.
>
> Granted, disk drive space has come down in price a lot since I ran into the
> issue and switched to using a custom port, but there are also new systems
> such as raspberry pi, that normally run from an sd card, which limits the
> drive size.

I've writ a number of special-purpose apps for PIs, but
yes, the space issue requires a lot of thought. You CAN
attach a USB SSD or even an efficient USB HD (have a 3tb
one attached to one Pi)

Another work around, if available, is to use an SMB share
on an NAS or something.

The sad thing about PI's isn't their capabilities, but
the POWER CONSUMPTION. That severely limits them for
"off grid" uses. Less impressive units like BeagleBone's
and esp Arduino's let you turn off basically every
peripherial until it's needed, and then cut it off again.
You can even tweak the CPU speed dynamically. You can
run an Ard off a mere 3-watt solar cell - though 5w is
safer - (use Seeed's LipoRider Pro to charge the battery !)
so long as you are taking samples at intervals (data-logger
type use).

Now as for SSH logs ... yea ... if possible NEVER expose
the standard port. I don't even use it on local networks.

The downside is that while the logs will tell you a lot
of things you have to FIGURE OUT what they're trying to
tell you. Various kinds of attacks (and simple faults)
don't always stand out very well.

Again another place where "AI"-style pattern detection
might be of use. Yer PC should *tell YOU* when there
might be a problem. If you routinely deal with a lot
of boxes, lots of net-connected boxes esp, you can
blow the entire day trying to dig though those logs
in search of a "something".

On Fri, 23 Dec 2022 22:36:50 -0500, 26C.Z969 wrote:
>
> On 12/17/22 10:30 AM, David W. Hodgins wrote:
>
>> When you get a few dozen hits per minute, it doesn't take a week to
>> use a lot
>> of log space. Rotating more often will mean info will be removed
>> sooner too.
>> Granted, disk drive space has come down in price a lot since I ran
>> into the
>> issue and switched to using a custom port, but there are also new systems
>> such as raspberry pi, that normally run from an sd card, which limits the
>> drive size.
>
> I've writ a number of special-purpose apps for PIs, but
> yes, the space issue requires a lot of thought. You CAN
> attach a USB SSD or even an efficient USB HD (have a 3tb
> one attached to one Pi)

"pi" also seems to be a famous username for trying to get into a
computer, as I can see in my logs.

| 2022-12-23T03:06:33.815375-05:00 localhost sshd[22509]: Failed password for invalid user pi from 89.109.32.143 port 24603 ssh2

Got tons of these, next to "admin".

Recently I allowed the scammers "SSH access" again. Not limiting it to
192.168.0.0 anymore, to get some log entries.

Btw. the IP attempting from in this extract is from Russia. Could be a
hacked computer though.
--
Andreas

26C.Z969 <26C.Z969@noaada.net> wrote:
>
> The sad thing about PI's isn't their capabilities, but
> the POWER CONSUMPTION. That severely limits them for
> "off grid" uses. Less impressive units like BeagleBone's
> and esp Arduino's let you turn off basically every
> peripherial until it's needed, and then cut it off again.

You can do a bit of that with the Pis, though it doesn't save much.

> You can even tweak the CPU speed dynamically.

That's done by default with a Pi running Linux.

> You can
> run an Ard off a mere 3-watt solar cell - though 5w is
> safer - (use Seeed's LipoRider Pro to charge the battery !)
> so long as you are taking samples at intervals (data-logger
> type use).

I measured the power consumption of an original Pi Zero at 90mA
while doing nothing, peaking at 190mA during boot-up. So if it's
usually idling then that's only 0.45W from the 5V power supply, and
at worst it'll peak at about 1W.

Also if you set code running on the GPU, it continues going after
the CPU is shut down (with access to GPIO signals), at which
time the board only pulls 50mA (0.25W). If you worked really hard
you could probably get the GPU to "wake up" the CPU roughly like
microcontroller sleep-modes, based on the (incomplete) open-source
GPU firmware for the Pis which needs to start up the CPU at
power-on anyway.

The RPi Zero 2 is more power hungry than the original Zero.

--
__ __
#_ < |\| |< _#

On 24/12/2022 03:36, 26C.Z969 wrote:
> On 12/17/22 10:30 AM, David W. Hodgins wrote:
>> On Sat, 17 Dec 2022 03:47:12 -0500, Andreas Kohlbach
>> <ank@spamfence.net> wrote:
>>
>>> On Sat, 17 Dec 2022 02:03:27 -0500, David W. Hodgins wrote:
>>>>
>>>> On Fri, 16 Dec 2022 21:24:46 -0500, Andreas Kohlbach
>>>> <ank@spamfence.net> wrote:
>>>>
>>>>> On Fri, 16 Dec 2022 10:30:17 +0100, Carlos E. R. wrote:
>>>>>>
>>>>> Nah, don't. Have them have their fun. They don't know root won't
>>>>> get in
>>>>> and waste their own resources. Although today it won't matter
>>>>> either. But
>>>>> not letting them know they cannot login as root they keep trying
>>>>> instead
>>>>> of wandering off and try other servers where they might be successful.
>>>>>
>>>>>> That's something a human operator would do.
>>>>>
>>>>> I don't think so. Unless being DDoSed. But then you have to take a
>>>>> completely different approach to mitigate the traffic.
>>>>
>>>> I don't block, but I use a non-standard port. Otherwise failed attempts
>>>> can fill the filesystem where the logs are stored. I had that happen
>>>> before
>>>> I switched ports.
>>>
>>> There's logrotate to take care of logfile sizes.
>>>
>>> ~$ ls -lrt /var/log/auth*
>>> -rw-r----- 1 root adm  78358 Nov 19 23:39 /var/log/auth.log.4.gz
>>> -rw-r----- 1 root adm  83875 Nov 26 23:57 /var/log/auth.log.3.gz
>>> -rw-r----- 1 root adm  44726 Dec  3 23:46 /var/log/auth.log.2.gz
>>> -rw-r----- 1 root adm 449644 Dec 10 23:51 /var/log/auth.log.1
>>> -rw-r----- 1 root adm 987377 Dec 17 03:45 /var/log/auth.log
>>
>> When you get a few dozen hits per minute, it doesn't take a week to
>> use a lot
>> of log space. Rotating more often will mean info will be removed
>> sooner too.
>>
>> Granted, disk drive space has come down in price a lot since I ran
>> into the
>> issue and switched to using a custom port, but there are also new systems
>> such as raspberry pi, that normally run from an sd card, which limits the
>> drive size.
>
>   I've writ a number of special-purpose apps for PIs, but
>   yes, the space issue requires a lot of thought. You CAN
>   attach a USB SSD or even an efficient USB HD (have a 3tb
>   one attached to one Pi)
>
>   Another work around, if available, is to use an SMB share
>   on an NAS or something.
>
My Pi has 2TB of NFS attached storage ;-)

--
"I guess a rattlesnake ain't risponsible fer bein' a rattlesnake, but ah
puts mah heel on um jess the same if'n I catches him around mah chillun".

Nevermind, I will just write my own.

On 12/23/22 11:26 PM, Andreas Kohlbach wrote:
> On Fri, 23 Dec 2022 22:36:50 -0500, 26C.Z969 wrote:
>>
>> On 12/17/22 10:30 AM, David W. Hodgins wrote:
>>
>>> When you get a few dozen hits per minute, it doesn't take a week to
>>> use a lot
>>> of log space. Rotating more often will mean info will be removed
>>> sooner too.
>>> Granted, disk drive space has come down in price a lot since I ran
>>> into the
>>> issue and switched to using a custom port, but there are also new systems
>>> such as raspberry pi, that normally run from an sd card, which limits the
>>> drive size.
>>
>> I've writ a number of special-purpose apps for PIs, but
>> yes, the space issue requires a lot of thought. You CAN
>> attach a USB SSD or even an efficient USB HD (have a 3tb
>> one attached to one Pi)
>
> "pi" also seems to be a famous username for trying to get into a
> computer, as I can see in my logs.

The recent Raspbian incarnations allow you to set the
default user name during install, even encourage you NOT
to use "pi".

Of course "pi" is perfectly good IF you use a decent PW.
For SSH, set very low limits on tries from one IP and on
parallel login threads. I doubt you need to use a PI
to handle all commercial internet traffic so you can
be very anal about that stuff.

> | 2022-12-23T03:06:33.815375-05:00 localhost sshd[22509]: Failed password for invalid user pi from 89.109.32.143 port 24603 ssh2
>
> Got tons of these, next to "admin".
>
> Recently I allowed the scammers "SSH access" again. Not limiting it to
> 192.168.0.0 anymore, to get some log entries.

Experiments CAN be enlightening :-)

Every so often I set firewall rule #1 to allow all - and
log it. Just for five minutes or so of course. The results
can be, well, "interesting" ...

> Btw. the IP attempting from in this extract is from Russia. Could be a
> hacked computer though.

"admin" is the other common 'default' (sometimes irreplacable)
user name on zillions of devices and apps.

Again, use a decent PW or even more and you'll be OK.

On 12/24/22 8:49 AM, The Natural Philosopher wrote:
> On 24/12/2022 03:36, 26C.Z969 wrote:
>> On 12/17/22 10:30 AM, David W. Hodgins wrote:
>>> On Sat, 17 Dec 2022 03:47:12 -0500, Andreas Kohlbach
>>> <ank@spamfence.net> wrote:
>>>
>>>> On Sat, 17 Dec 2022 02:03:27 -0500, David W. Hodgins wrote:
>>>>>
>>>>> On Fri, 16 Dec 2022 21:24:46 -0500, Andreas Kohlbach
>>>>> <ank@spamfence.net> wrote:
>>>>>
>>>>>> On Fri, 16 Dec 2022 10:30:17 +0100, Carlos E. R. wrote:
>>>>>>>
>>>>>> Nah, don't. Have them have their fun. They don't know root won't
>>>>>> get in
>>>>>> and waste their own resources. Although today it won't matter
>>>>>> either. But
>>>>>> not letting them know they cannot login as root they keep trying
>>>>>> instead
>>>>>> of wandering off and try other servers where they might be
>>>>>> successful.
>>>>>>
>>>>>>> That's something a human operator would do.
>>>>>>
>>>>>> I don't think so. Unless being DDoSed. But then you have to take a
>>>>>> completely different approach to mitigate the traffic.
>>>>>
>>>>> I don't block, but I use a non-standard port. Otherwise failed
>>>>> attempts
>>>>> can fill the filesystem where the logs are stored. I had that
>>>>> happen before
>>>>> I switched ports.
>>>>
>>>> There's logrotate to take care of logfile sizes.
>>>>
>>>> ~$ ls -lrt /var/log/auth*
>>>> -rw-r----- 1 root adm  78358 Nov 19 23:39 /var/log/auth.log.4.gz
>>>> -rw-r----- 1 root adm  83875 Nov 26 23:57 /var/log/auth.log.3.gz
>>>> -rw-r----- 1 root adm  44726 Dec  3 23:46 /var/log/auth.log.2.gz
>>>> -rw-r----- 1 root adm 449644 Dec 10 23:51 /var/log/auth.log.1
>>>> -rw-r----- 1 root adm 987377 Dec 17 03:45 /var/log/auth.log
>>>
>>> When you get a few dozen hits per minute, it doesn't take a week to
>>> use a lot
>>> of log space. Rotating more often will mean info will be removed
>>> sooner too.
>>>
>>> Granted, disk drive space has come down in price a lot since I ran
>>> into the
>>> issue and switched to using a custom port, but there are also new
>>> systems
>>> such as raspberry pi, that normally run from an sd card, which limits
>>> the
>>> drive size.
>>
>>    I've writ a number of special-purpose apps for PIs, but
>>    yes, the space issue requires a lot of thought. You CAN
>>    attach a USB SSD or even an efficient USB HD (have a 3tb
>>    one attached to one Pi)
>>
>>    Another work around, if available, is to use an SMB share
>>    on an NAS or something.
>>
> My Pi has 2TB of NFS attached storage ;-)

I use one PI as a 3rd-tier backup device - and it has
a 3tb USB HDD as space - almost exactly the same physical
size as the Pi.It's been doing its thing for a few years
now. The newer USB SSDs are also moving into an attractive
price/capacity range now (though supply issues do seem to
be a damper there).

The device duplicates compressed backups prepped by
the main backup box the night before - so it doesn't
matter if the Pi is notably slower.

I'd strongly rec the Samsung Evo's - top quality and
you can get 1tb for like $89 on Amazon lately. The
"quads" ... um ... OK I guess, more TB/$ ... but they
are slower and the tech is alleged to be a bit less
reliable. The original "single density" "Pro" 860 line
seems to have disappeared.

There are also rather large ordinary USB sticks these
days ... but their reliability is ... well .......

In any case, you CAN attach quite a lot of storage to
a Pi at a fair price. DO write yer apps so they CHECK
to see if the device is ACTUALLY mounted though. Linux
can be a bit stupid in that respect and you'll just
overwhelm your primary almost instantly as all yer
files get moved to your mountPOINT instead of the
actual larger mount. Mounting of USBs should always
be CONFIRMED. Even a simple size check will provide
the needed info.

On 12/23/22 11:37 PM, Computer Nerd Kev wrote:
> 26C.Z969 <26C.Z969@noaada.net> wrote:
>>
>> The sad thing about PI's isn't their capabilities, but
>> the POWER CONSUMPTION. That severely limits them for
>> "off grid" uses. Less impressive units like BeagleBone's
>> and esp Arduino's let you turn off basically every
>> peripherial until it's needed, and then cut it off again.
>
> You can do a bit of that with the Pis, though it doesn't save much.

No, not much at all. I also do "embedded" and field
datalogger apps - and unless you want a rather large
solar panel and battery the Pi's are totally unsuitable
Microcontroller-based is MUCH better - but they're
normally not gonna be Linux ... dedicated 'C' app instead.

>
>> You can even tweak the CPU speed dynamically.
>
> That's done by default with a Pi running Linux.

Um ... not nearly enough.

Some microcontrollers can go fully static - just
waiting for an interrupt to spring into action.

>> You can
>> run an Ard off a mere 3-watt solar cell - though 5w is
>> safer - (use Seeed's LipoRider Pro to charge the battery !)
>> so long as you are taking samples at intervals (data-logger
>> type use).
>
> I measured the power consumption of an original Pi Zero at 90mA
> while doing nothing, peaking at 190mA during boot-up. So if it's
> usually idling then that's only 0.45W from the 5V power supply, and
> at worst it'll peak at about 1W.

Arduino's can be shut down to micro-watt levels between
bursts of activity. Some PICs can theoretically do
nano-watts and they're not even cutting edge anymore.
I did a bunch of field dataloggers based on the Ard Mega -
with a flash-drive shield attached. Do yer collection
every 15 or 30 minutes, write it to the flash, then set
the thing stone cold until the next timer-chip pulse.
You can cut out the 3.3v regulator and dump the I2C
resistor in favor of a pin you power-up yerself at
the correct time. Smash the power LED too :-)

Those WOULD run from a mere 3w solar panel and lipo
battery ... UNLESS the skies were cloudy too often.
So, I changed to a 5w panel and that fixed it.

> Also if you set code running on the GPU, it continues going after
> the CPU is shut down (with access to GPIO signals), at which
> time the board only pulls 50mA (0.25W). If you worked really hard
> you could probably get the GPU to "wake up" the CPU roughly like
> microcontroller sleep-modes, based on the (incomplete) open-source
> GPU firmware for the Pis which needs to start up the CPU at
> power-on anyway.

I had considered using a microcontroller to wake up a Pi
when needed - and for some kinds of apps that might be
reasonable. What I was doing, no, just stick with
microcontroller-based hardware in the first place.

> The RPi Zero 2 is more power hungry than the original Zero.

Well, faster ... there IS a price.

Oh, there's a REASON I said to use the Seeed Lipo-Rider Pro ...

CHECK what voltage you're getting from some of the other
lipo chargers (at low consumption levels) and you'll find
they go WAY out of spec when the sun comes up really bright,
enough to do damage. The Lipo-Rider Pro HOLDS its 5.5v
rock steady though.

On 26/12/2022 06:14, 26C.Z969 wrote:
> On 12/23/22 11:26 PM, Andreas Kohlbach wrote:
>> On Fri, 23 Dec 2022 22:36:50 -0500, 26C.Z969 wrote:
>>>
>>> On 12/17/22 10:30 AM, David W. Hodgins wrote:
>>>
>>>> When you get a few dozen hits per minute, it doesn't take a week to
>>>> use a lot
>>>> of log space. Rotating more often will mean info will be removed
>>>> sooner too.
>>>> Granted, disk drive space has come down in price a lot since I ran
>>>> into the
>>>> issue and switched to using a custom port, but there are also new
>>>> systems
>>>> such as raspberry pi, that normally run from an sd card, which
>>>> limits the
>>>> drive size.
>>>
>>>    I've writ a number of special-purpose apps for PIs, but
>>>    yes, the space issue requires a lot of thought. You CAN
>>>    attach a USB SSD or even an efficient USB HD (have a 3tb
>>>    one attached to one Pi)
>>
>> "pi" also seems to be a famous username for trying to get into a
>> computer, as I can see in my logs.
>
>   The recent Raspbian incarnations allow you to set the
>   default user name during install, even encourage you NOT
>   to use "pi".
>
I have an older one, but I edited (as root) the /etc/passwd file and set
user 1000 to my name.
And set it up with a different password

>   Of course "pi" is perfectly good IF you use a decent PW.
>   For SSH, set very low limits on tries from one IP and on
>   parallel login threads. I doubt you need to use a PI
>   to handle all commercial internet traffic so you can
>   be very anal about that stuff.

--
Of what good are dead warriors? … Warriors are those who desire battle
more than peace. Those who seek battle despite peace. Those who thump
their spears on the ground and talk of honor. Those who leap high the
battle dance and dream of glory … The good of dead warriors, Mother, is
that they are dead.
Sheri S Tepper: The Awakeners.

On 12/26/22 3:01 PM, The Natural Philosopher wrote:
> On 26/12/2022 06:14, 26C.Z969 wrote:
>> On 12/23/22 11:26 PM, Andreas Kohlbach wrote:
>>> On Fri, 23 Dec 2022 22:36:50 -0500, 26C.Z969 wrote:
>>>>
>>>> On 12/17/22 10:30 AM, David W. Hodgins wrote:
>>>>
>>>>> When you get a few dozen hits per minute, it doesn't take a week to
>>>>> use a lot
>>>>> of log space. Rotating more often will mean info will be removed
>>>>> sooner too.
>>>>> Granted, disk drive space has come down in price a lot since I ran
>>>>> into the
>>>>> issue and switched to using a custom port, but there are also new
>>>>> systems
>>>>> such as raspberry pi, that normally run from an sd card, which
>>>>> limits the
>>>>> drive size.
>>>>
>>>>    I've writ a number of special-purpose apps for PIs, but
>>>>    yes, the space issue requires a lot of thought. You CAN
>>>>    attach a USB SSD or even an efficient USB HD (have a 3tb
>>>>    one attached to one Pi)
>>>
>>> "pi" also seems to be a famous username for trying to get into a
>>> computer, as I can see in my logs.
>>
>>    The recent Raspbian incarnations allow you to set the
>>    default user name during install, even encourage you NOT
>>    to use "pi".
>>
> I have an older one, but I edited (as root) the /etc/passwd file and set
> user 1000 to my name.
> And set it up with a different password

Easiest way if you're paranoid about "pi". You can
also just create a new user and then move the various
permissions from 'pi' to that and disable/hide "pi".

I don't think the usual full-number upgrade procedure
will give you the op to change user 1000, just a from-
scratch.

I still think 'Raspbian' is the best for the Pi. It
is best attuned to the board. Sure, you can run a bunch
of different systems on it - most any 'buntu derivative,
I've run OpenSUSE Tweed, and a few odd ones (even BSDs) -
but with Raspbian you are sure to get all the needed
libraries and utilities and such plus it IS Debian/LX
under the hood and thus a damned good system. Do NOT
like the shift to LXQT however ... it has weird problems.
XFCE is the logical replacement, or bite it and force LXDE
back in there.

Oh, not long back I discovered a Pi v1 'B' (256mb with fewer
pins than the newer ones) was still doing its one little
service in the back of the IT cave with its ancient Wheezy
release (kernel 3.6). It's not online so security updates
are irrelevant. Installed the Buster (all platform) Raspbian
Lite out of pity on a fresh flash card and it worked just
perfectly. Good for another decade probably. I like that kind
of backwards compatibility ... kinda like if you could install
Win11 on a PC-XT :-)

>>    Of course "pi" is perfectly good IF you use a decent PW.
>>    For SSH, set very low limits on tries from one IP and on
>>    parallel login threads. I doubt you need to use a PI
>>    to handle all commercial internet traffic so you can
>>    be very anal about that stuff.
>

26C.Z969 <26C.Z969@noaada.net> wrote:
> On 12/23/22 11:37 PM, Computer Nerd Kev wrote:
>> 26C.Z969 <26C.Z969@noaada.net> wrote:
>>>
>>> The sad thing about PI's isn't their capabilities, but
>>> the POWER CONSUMPTION. That severely limits them for
>>> "off grid" uses. Less impressive units like BeagleBone's
>>> and esp Arduino's let you turn off basically every
>>> peripherial until it's needed, and then cut it off again.
[snip]
>> Also if you set code running on the GPU, it continues going after
>> the CPU is shut down (with access to GPIO signals), at which
>> time the board only pulls 50mA (0.25W). If you worked really hard
>> you could probably get the GPU to "wake up" the CPU roughly like
>> microcontroller sleep-modes, based on the (incomplete) open-source
>> GPU firmware for the Pis which needs to start up the CPU at
>> power-on anyway.
>
> I had considered using a microcontroller to wake up a Pi
> when needed - and for some kinds of apps that might be
> reasonable. What I was doing, no, just stick with
> microcontroller-based hardware in the first place.

For what you were doing you didn't need any of the Pi's features
anyway, so I'm not sure why you were sad that you couldn't use one.

--
__ __
#_ < |\| |< _#

On 12/26/22 5:33 PM, Computer Nerd Kev wrote:
> 26C.Z969 <26C.Z969@noaada.net> wrote:
>> On 12/23/22 11:37 PM, Computer Nerd Kev wrote:
>>> 26C.Z969 <26C.Z969@noaada.net> wrote:
>>>>
>>>> The sad thing about PI's isn't their capabilities, but
>>>> the POWER CONSUMPTION. That severely limits them for
>>>> "off grid" uses. Less impressive units like BeagleBone's
>>>> and esp Arduino's let you turn off basically every
>>>> peripherial until it's needed, and then cut it off again.
> [snip]
>>> Also if you set code running on the GPU, it continues going after
>>> the CPU is shut down (with access to GPIO signals), at which
>>> time the board only pulls 50mA (0.25W). If you worked really hard
>>> you could probably get the GPU to "wake up" the CPU roughly like
>>> microcontroller sleep-modes, based on the (incomplete) open-source
>>> GPU firmware for the Pis which needs to start up the CPU at
>>> power-on anyway.
>>
>> I had considered using a microcontroller to wake up a Pi
>> when needed - and for some kinds of apps that might be
>> reasonable. What I was doing, no, just stick with
>> microcontroller-based hardware in the first place.
>
> For what you were doing you didn't need any of the Pi's features
> anyway, so I'm not sure why you were sad that you couldn't use one.

Lusted for periodic photos of the environment ... and
few microcontrollers have enough RAM or speed to cope.
They will work OK with a cellular modem though.

These days you can buy all that and more off the $helf ;
try the smart ag or environmental-management suppliers.
Much more fun wiring yer own though :-)

On 12/15/22 01:52, 26C.Z969 wrote:
> SSH is a good oldie for sure. However, it seems to
> be increasingly unfit for the modern realities.

what bullshit

On 12/16/22 00:16, 26C.Z969 wrote:
> In the end I may HAVE to

Good! Let us know when you have it released under the GPL

On 12/26/22 7:41 PM, Popping Mad wrote:
> On 12/15/22 01:52, 26C.Z969 wrote:
>> SSH is a good oldie for sure. However, it seems to
>> be increasingly unfit for the modern realities.
>
>
> what bullshit

Thank you for your constructive input.

Nevermind ... SSH beyond perfect even in a
world of mass distributed attacks ... just
keep repeating that ......... :-)

Decided to write my own replacement. It won't
be freeware ...

On 12/26/22 7:45 PM, Popping Mad wrote:
> On 12/16/22 00:16, 26C.Z969 wrote:
>> In the end I may HAVE to
>
>
> Good! Let us know when you have it released under the GPL

No, not GPL ... $$$ :-)

On 12/17/22 9:21 AM, Rich wrote:
> 26C.Z969 <26C.Z969@noaada.net> wrote:
>> Not so long ago, I was working on the weekend and watched one of
>> these attacks take shape. First it was one IP address showing up
>> in the firewall logs. Did a simple conservative /24 block on it.
>> Half an hour later MORE probes showed up - first from a few
>> addresses, then dozens, then hundreds banging at it as fast as they
>> could. Even looking at the detailed connection info revealed no
>> common factors you could filter. Dunno if this was one bot or the
>> "hot" address was shared around. So, as I was pretty much the only
>> one using it (and it was NOT p22 - never use that !) I just changed
>> the external port number. However for TEN MONTHS there were
>> literally a thousand+ probes a day on that old, dead, port.
>>
>> This is where I concluded that SSH was not fit for the modern
>> world. It's not "smart" enough.
>
> Please enlighten us then as to how your proposed "replacement", given
> the same situation as you detail above, was to be somehow 'smarter'
> and be able to control the actions of actors elsewhere on the internet.
>
> What would this 'smarter' replacement do, given what happened "not so
> long ago"?

I am currently studying "AI" pattern-recognition techniques.
So far as I can surmise, distributed attacks seem to follow
certain *patterns*, also tend to re-use undefended IP addresses.
These are things an "AI" can be trained to detect - and then
train itself to do even better.

Any human can look at a log or two and say "Attack !" - IMHO
The System ought to be able to do that by itself, and learn
and educate other systems.

This is NOT far from the existing concept of SPAM blacklists
but I want slightly more general, and evolving, rules.

But you don't have to worry about any of this ... everything's
cool ... that 50 year old interface is Just Fine ...........

"26C.Z969" <26C.Z969@noaada.net> writes:
> Nevermind, I will just write my own.

Perhaps you can explain how it will differ from SSH. To make it a
concrete question: how will the key exchange process differ?

--
https://www.greenend.org.uk/rjk/

26C.Z969 <26C.Z969@noaada.net> wrote:
> On 12/17/22 9:21 AM, Rich wrote:
>> What would this 'smarter' replacement do, given what happened "not so
>> long ago"?
>
> I am currently studying "AI" pattern-recognition techniques.
> So far as I can surmise, distributed attacks seem to follow
> certain *patterns*, also tend to re-use undefended IP addresses.
> These are things an "AI" can be trained to detect - and then
> train itself to do even better.
>
> Any human can look at a log or two and say "Attack !" - IMHO
> The System ought to be able to do that by itself, and learn
> and educate other systems.

The most effective response to a distributed attack will just be
for it to block _all_ SSH connections, with effectiveness
decreasing from that point as it invents ways to try and ID real
humans. But I don't see how those ways can be reliable - it can
only end up blocking genuine users who happen to pop up in an IP
range that's also used by attackers, or who'se software
configuration happens to look like an attacker's. That in turn is
likely to cause more trouble than a brute-force attack would have.

I don't see how a human looking at logs is supposed to solve this
problem, let alone an AI.

> This is NOT far from the existing concept of SPAM blacklists
> but I want slightly more general, and evolving, rules.

Yeah exactly, it would make SSH log-in as hopelessly unreliable as
email delivery. Oh wait, you think SPAM blacklists _are_ actually
smart...

--
__ __
#_ < |\| |< _#

On 12/28/22 4:37 PM, Computer Nerd Kev wrote:
> 26C.Z969 <26C.Z969@noaada.net> wrote:
>> On 12/17/22 9:21 AM, Rich wrote:
>>> What would this 'smarter' replacement do, given what happened "not so
>>> long ago"?
>>
>> I am currently studying "AI" pattern-recognition techniques.
>> So far as I can surmise, distributed attacks seem to follow
>> certain *patterns*, also tend to re-use undefended IP addresses.
>> These are things an "AI" can be trained to detect - and then
>> train itself to do even better.
>>
>> Any human can look at a log or two and say "Attack !" - IMHO
>> The System ought to be able to do that by itself, and learn
>> and educate other systems.
>
> The most effective response to a distributed attack will just be
> for it to block _all_ SSH connections, with effectiveness
> decreasing from that point as it invents ways to try and ID real
> humans.

I've personal experience with such attacks lasting MONTHS -
even AFTER I changed SSH to a new net-facing port. Once one
bot finds an interesting port it passes the info along.
Such is the modern world. So ... blocking all traffic
is in NO way a viable defense.

For LOW-traffic use, stuff like port-knocking might suffice.
But when you HAVE to make room for a lot of users then the
situation becomes rather grim.

As noted early on however, access via SSH is maybe no
longer the most popular way to access a remote system.
LOTS of "server management" apps using https for
encryption - inc SolarWinds - takes a far more web-based
approach. Others use rather standard alternative ports -
and the little bots know all about them.

Hmmm ... maybe the thread should have been titled
"Is SSH Even Worth It Anymore ?" :-)

> But I don't see how those ways can be reliable - it can
> only end up blocking genuine users who happen to pop up in an IP
> range that's also used by attackers, or who'se software
> configuration happens to look like an attacker's. That in turn is
> likely to cause more trouble than a brute-force attack would have.
>
> I don't see how a human looking at logs is supposed to solve this
> problem, let alone an AI.

A human can SEE it ... "solving" it is something else entirely.

My HOPE is that there are patterns to such attacks, and "AI"
at this juncture is very good at spotting patterns. What
IP addresses are used, what frequency are they used, what
quirks in the auth process, any geo-relevant aspects ???

>> This is NOT far from the existing concept of SPAM blacklists
>> but I want slightly more general, and evolving, rules.
>
> Yeah exactly, it would make SSH log-in as hopelessly unreliable as
> email delivery. Oh wait, you think SPAM blacklists _are_ actually
> smart...

I rarely have problems logging into mail servers ...

SPAM blacklists are "quasi-smart" - and DO block rather
a lot of SPAM sources. I see this in the mail server logs
every day. However I'm not sure how AUTOMATED they are
behind the scenes. Who/how-many update the databases
and say "THESE people are SPAMMERS" ? I've even seen
those blacklists ABUSED ... fake reports designed to
hurt Company-X. Getting yourself OFF those blacklists
can be a chore ... and if VadeSecure hates you then
you're in deep shit.

I'm looking into finding the abovementioned kinds of
patterns to big bot attacks - and that "intelligence"
COULD be dynamically updated, shared to all. Even
the web-based remote-access methods can be afflicted
by a zillion-bot attack, so this isn't JUST an SSH thing.

But I'm not gonna have it by the end of the week.

MAYBE this thread will prompt OTHERS to look into
this stuff ? "AI" is not my strong suite and it's
gonna take awhile. OTHERS are really into it though.

On 12/18/22 6:59 PM, Carlos E. R. wrote:
> On 19/12/2022 00.47, Andreas Kohlbach wrote:
>> On Sun, 18 Dec 2022 23:35:23 +0100, Carlos E. R. wrote:
>>>
>>> On 18/12/2022 02.13, Andreas Kohlbach wrote:
>>>>
>>>> I was referring to "can fill the filesystem".
>>>
>>> Yes, rotating logs takes care of that. But the issue of too much noise
>>> remains.
>>
>> The typical Linux user of today can ignore the noise. Ignore your logs,
>> unless you feel something is not right.
>
> I work the other way:
> I check the logs to see if there is something wrong :-)

Indeed ! :-)

The "Everything *SEEMS* OK" approach is the short path
to disaster.

All the while the little termites are chewing-away at
yer foundations .......

Every day, sometimes twice a day, I look at the mail
server logs, the firewall logs and SSH logs. Very
often things are NOT as safe and secure as they *seem*.

Checked the firewall logs Xmas evening - and yep, over
4000 tries from a (fortunately narrow) range of addresses
(DigitalOcean, of course, meaning "probably Russians")
running linearly up the port spectrum with multiple kinds
of login protocols to maybe figure out what was there.
Probably an nmap or related sort of scan. Even included
RTSP. They got a /16 scale block. But everything *seemed ok* -
until you LOOKED. Once they'd found what they wanted they'd
have proceeded with the brute-force attacks on the 'hot'
ports for hours/days/weeks/months ...... it ain't humans,
it's bots - they are legion and they never need to sleep.

SSH can do a "login message" - point to a file. Mine
delivers a 8k long "message" including all sorts of
words that you'd kinda expect if you were trying to
log in. MAYbe it confuses bots, makes 'em send their
auth tries too soon ... maybe. Doesn't hurt anything.

On Thu, 29 Dec 2022 00:02:46 -0500, 26C.Z969 wrote:
>
> On 12/28/22 4:37 PM, Computer Nerd Kev wrote:
>>
>> The most effective response to a distributed attack will just be
>> for it to block _all_ SSH connections, with effectiveness
>> decreasing from that point as it invents ways to try and ID real
>> humans.
>
> I've personal experience with such attacks lasting MONTHS -
> even AFTER I changed SSH to a new net-facing port. Once one
> bot finds an interesting port it passes the info along.
> Such is the modern world. So ... blocking all traffic
> is in NO way a viable defense.

There is no real threat in my opinion, unless you use weak passwords. And
a little hardening might take away the paranoia: Allow only specific
users. Then no one gets in even if he guesses the right account name
(like "pi" as discussed earlier) and password. Unless you have an account
id "pi" and a weak password.

Or use host-keys. No one gets in, unless s/he has the right key.

The traffic will persist, so what. It's like you wish to sush people on
the streets from chatting, because you don't like the noise. Won't
happen. Just ignore it.
--
Andreas

On 12/29/22 1:33 AM, Andreas Kohlbach wrote:
> On Thu, 29 Dec 2022 00:02:46 -0500, 26C.Z969 wrote:
>>
>> On 12/28/22 4:37 PM, Computer Nerd Kev wrote:
>>>
>>> The most effective response to a distributed attack will just be
>>> for it to block _all_ SSH connections, with effectiveness
>>> decreasing from that point as it invents ways to try and ID real
>>> humans.
>>
>> I've personal experience with such attacks lasting MONTHS -
>> even AFTER I changed SSH to a new net-facing port. Once one
>> bot finds an interesting port it passes the info along.
>> Such is the modern world. So ... blocking all traffic
>> is in NO way a viable defense.
>
> There is no real threat in my opinion, unless you use weak passwords. And
> a little hardening might take away the paranoia: Allow only specific
> users. Then no one gets in even if he guesses the right account name
> (like "pi" as discussed earlier) and password. Unless you have an account
> id "pi" and a weak password.

You mean "123" isn't good ??? :-)

In my current groove I *can* restrict users a fair bit.
That's just ME though - others need to deal with lots
of users who may be connecting through almost any IP
address that day.

> Or use host-keys. No one gets in, unless s/he has the right key
The "tighter" things are the HARDER for the regular
users things become too. Pretty quick they petition
a know-nothing boss to cut the crap, or find sneaky
bypasses.

But I'm not sure if there's a good way to make it easy
for the good guys and hell for the others. Everyone
from the giant tech corps on down have been looking,
but so far ......

> The traffic will persist, so what. It's like you wish to sush people on
> the streets from chatting, because you don't like the noise. Won't
> happen. Just ignore it.

Not wise to take that tact TOO far .......

In any event, I asked a question somewhere upstream
about whether SSH might be kinda *obsolete* at this
point. SO much access is now via browser-based apps.
They are as vulnerable in their ways as SSH, but they
are the *preferred* access method now. MAYbe the solution
to SSH is to just turn it OFF forever ?