Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On 31 Jan 2024 13:40:11 +0000 (GMT)
> Theo <theom+news@chiark.greenend.org.uk> wrote:
>
> > A one liner to disable password auth, works on Ubuntu and Raspberry Pi OS:
> > echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/10-passwordauth.conf ; sudo service ssh reload
>
> It will work on just about any unixish system with sshd.

It depends on having this line at the top of your /etc/ssh/sshd_config:

Include /etc/ssh/sshd_config.d/*.conf

otherwise the folder sshd_config.d would be ignored. I know Ubuntu and
Raspbian ship with that line in the default config (after ~2018), but
couldn't speak for other distros.

Theo

Chris Green <cl@isbd.net> wrote:
> I don't disagreee with what you're saying but there's a load of
> configuration to do it all if, as is often the case, I'm rebuilding a
> Raspberry Pi for example.

On your machine:

ssh-copy-id pi@raspberrypi

On the Pi:
echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/10-passwordauth.conf ; sudo service ssh reload

That's it. Two lines.

> "If you never send the password there's nothing to keylog or
> phish" Ay? If there's a keylogger on your system it doesn't care
> whether you're typing a password or a key. If it's logging what's
> sent over the wire then it's encrypted.

The keylogger is often in a compromised SSH daemon on the server, rather
than in your machine. You connect to the server, it sees your password as
you type it, it records your password and tries to login to other machines
using it.

With keys, you never send the private key or passphrase over the connection.
You tell your SSH client which key to use (or it tries several). The SSH
client asks you for the passphrase to unlock the key (which is happening
locally). You tell teh server which key you're using and it checks your
authorized_keys for that public key.

The site sends you a challenge based on the public key, you compose a
response to your challenge using the private key, you send the response.
If the server can decrypt the response you are in possession of the private
key and the server proceeds to generate keys for this session.

If the keylogger is on your machine, it can get the passphrase but it
doesn't get the private key unless it is specifically designed for attacking
ssh and can read your private keys. eg you might see the following in the
keylog:

ssh chris@server.bigcorp.com
abr@cad4bra
ls

and it's clear that abr@cad4bra is your password. If that was your
passphrase it wouldn't help attack anyone.

> You **have** to start with password authentication so it's inevitably
> there when you start with your headless Pi. Everything more to move
> to one key per remote system is extra hassle which I have to repeat
> when I rebuild the Pi (which can be quite frequently, e.g. two or
> three times in a week).

You don't have to start with password auth. rpi-imager will allow you to
install a public key into the Pi so you can SSH directly using keys. It
will also remember your settings so every time you flash a Pi, it gets your
keys automatically.

> So generate key (OK, that's only once per physical system), copy the
> key to the remote using ssh-copy-id. Then go to the remote and edit
> /etc/ssh/sshd_config, then reboot and check it all works. Not a load
> of work but enough to be a bit of a pain, plus I like to record
> configuration changes (like the sshd_config one).

etckeeper will keep track of changes to /etc in a git repo

If you want to do this to a lot of machines, it's worth learning Ansible as
it'll keep your fleet of machines in sync. Just write an ansible recipe
and it will ensure it is applied (and only once) across all your
machines.

Theo

On 2024-01-30, The Natural Philosopher wrote:

> On 30/01/2024 06:03, 68g.1499 wrote:
>> The continuing most-dangerous thing out there is not "hacking" but
>> "human factors" -
>
> My chief engineer went to do a security audit and install a corporate
> firewall, and then test it.
>
> His security report included:
>
> - "The widespread use of dial in modems connecting to users DDI ports to
> enable them to operate their windows desktop computers from home
> represents a far greater security risk than that offered by the internet
> connection....

How long ago was that?

> - "The list of root passwords pinned up behind the receptionist desk as
> well as the directory of usernames and DDI extensions is also sub
> optimal...

Brilliant.

On 2024-01-26, Theo wrote:

> More to the point it's now illegal to have default usernames and passwords
> in the UK, so the RPi folks have to comply.

Does that cover the RPi OS? The article I found (Nov. 2021) says

Included within its scope are a range of devices, from smartphones,
routers, security cameras, games consoles, home speakers and
internet-enabled white goods and toys.

But it does not include vehicles, smart meters and medical
devices. Desktop and laptop computers are also not in its remit.

<https://www.bbc.co.uk/news/technology-59400762>

Adam Funk <a24061@ducksburg.com> wrote:
> On 2024-01-26, Theo wrote:
>
> > More to the point it's now illegal to have default usernames and passwords
> > in the UK, so the RPi folks have to comply.
>
> Does that cover the RPi OS? The article I found (Nov. 2021) says
>
> Included within its scope are a range of devices, from smartphones,
> routers, security cameras, games consoles, home speakers and
> internet-enabled white goods and toys.
>
> But it does not include vehicles, smart meters and medical
> devices. Desktop and laptop computers are also not in its remit.
>
> <https://www.bbc.co.uk/news/technology-59400762>

https://www.legislation.gov.uk/ukpga/2022/46/contents/enacted

I'll leave you to follow through the logic (ss4-7), but RPi OS gets used in
a number of consumer and industrial products. If I were them I wouldn't
want to take a risk of being found in breach, even if some percentage of use
cases weren't covered by the Act. For one thing, even if the end
manufacturer is liable, RPi are still at risk from secondary lawsuits from
the manufacturer suing them.

The Act doesn't talk about 'smartphones, routers, cameras' etc - it just has
'internet-connectable products' and 'network-connectable products'. eg your
wifi cloud-controlled smart plug is an internet connectable product while a
Zigbee one isn't internet-connectable but is network-connectable. Smart
meters are network-connectable but not internet-connectable.

Theo

On 31/01/2024 16:02, Adam Funk wrote:
> On 2024-01-30, The Natural Philosopher wrote:
>
>> On 30/01/2024 06:03, 68g.1499 wrote:
>>> The continuing most-dangerous thing out there is not "hacking" but
>>> "human factors" -
>>
>> My chief engineer went to do a security audit and install a corporate
>> firewall, and then test it.
>>
>> His security report included:
>>
>> - "The widespread use of dial in modems connecting to users DDI ports to
>> enable them to operate their windows desktop computers from home
>> represents a far greater security risk than that offered by the internet
>> connection....
>
> How long ago was that?
>
1997 or something?

>
>> - "The list of root passwords pinned up behind the receptionist desk as
>> well as the directory of usernames and DDI extensions is also sub
>> optimal...
>
> Brilliant.

--
The theory of Communism may be summed up in one sentence: Abolish all
private property.

Karl Marx

On 31/01/2024 16:55, Theo wrote:
> I'll leave you to follow through the logic (ss4-7), but RPi OS gets used in
> a number of consumer and industrial products.

Then their *adapted* version of software will have its own username and
password .

A raspberry pi does not come equipped with even an operating system

--
Climate Change: Socialism wearing a lab coat.

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 31/01/2024 16:55, Theo wrote:
> > I'll leave you to follow through the logic (ss4-7), but RPi OS gets used in
> > a number of consumer and industrial products.
>
> Then their *adapted* version of software will have its own username and
> password .
>
> A raspberry pi does not come equipped with even an operating system

I'm sure you'll be happy to argue that with m'learned friends. I'm sure you
won't mind handing over "4% of the person’s qualifying worldwide revenue for
the [corporate] person’s most recent complete accounting period." if found
to be in breach, plus damages from everyone downstream who sues you.

Theo

On 2024-01-31, Adam Funk <a24061@ducksburg.com> wrote:

> On 2024-01-30, The Natural Philosopher wrote:
>
>> - "The list of root passwords pinned up behind the receptionist desk
>> as well as the directory of usernames and DDI extensions is also sub
>> optimal...
>
> Brilliant.

I laughed when the movie WarGames showed the protagonist sitting
outside the principal's office, sliding out the writing leaf on the
desk on which a terminal sat, to reveal a piece of paper with the
password written on it. It was the most realistic part of the movie.

--
/~\ Charlie Gibbs | The Internet is like a big city:
\ / <cgibbs@kltpzyxm.invalid> | it has plenty of bright lights and
X I'm really at ac.dekanfrus | excitement, but also dark alleys
/ \ if you read it the right way. | down which the unwary get mugged.

On 2024-01-31, Chris Green <cl@isbd.net> wrote:

> I've often looked at openVpn but always decided it was far more hassle
> than using ssh! :-) Admittedly I do 99% of my computing at the
> command line so an ssh connection is all I ever want.

And even GUI applications that don't rely on lots of animation
(e.g. Thunderbird for e-mail) work quite well with ssh -X.

--
/~\ Charlie Gibbs | The Internet is like a big city:
\ / <cgibbs@kltpzyxm.invalid> | it has plenty of bright lights and
X I'm really at ac.dekanfrus | excitement, but also dark alleys
/ \ if you read it the right way. | down which the unwary get mugged.

On 30/01/2024 23:39, Scott Alfter wrote:
> In article <upc13i$16fsg$1@dont-email.me>,
> Pancho <Pancho.Jones@proton.me> wrote:
>> On 30/01/2024 23:16, Scott Alfter wrote:
>>> For remote access (to a headless box or otherwise), you should be using
>>> key-based authentication anyway and should disable password authentication
>>> in sshd.
>>
>> What is the usuaL set up for a home LAN, one key to rule them all, or a
>> key for each machine?
>
> One key for each host that needs to connect. That way, if one of your
> computers gets stolen or is lost, you can revoke its access.
>

Yes, I understand the need for unique keys for clients which operate
outside the home, like a laptop, but what about for the LAN only
devices? For instance, a rPi using scp to another rPi. I have quite a
few Pis.

When I set up a new machine, it is often easier to use an existing key
which already has been installed on all SSH servers, so I use a single
one. Often, I just copy the ~/.ssh folder. I suppose I could reuse a
currently unused key from a pool of configured keys, but it seems like a
lot of work.

Chris Green <cl@isbd.net> writes:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> Chris Green <cl@isbd.net> writes:

>>> One argument against using key based authentication (in my case
>>> anyway) is that my home desktop and my laptop (which are the ssh
>>> clients) are turned on and logged-into just about all the time. Thus,
>>> with the default log-in key used for authentication, all my remote
>>> systems would be accessible to someone just walking up to desktop or
>>> laptop.
>>
>> If an attacker can just walk up to your computer and run commands on it
>> then they will install a keylogger and they will have any passwords you
>> use next time you type them.
>>
> That requires a knowledgeable attacker, just connection to a remote
> doesn't.

It’s a standard part of any attack toolkit. No real knowledge required.

> However this is all quite academic really. It's security the other
> way about (**into** my home system) that really matters.

If you’re not worried about the outbound connections then use keys and
save yourself the hassle of typing in passwords.

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

On 30/01/2024 23:35, Pancho wrote:
> I find it useful to have a weak point, one machine with password
> authentication, for that time I find myself on a machine without an
> appropriate key.

That's handy - for miscreants. I assume from that machine you can log in
to other machines on your network? If so they will be able too.

> What is the usuaL set up for a home LAN, one key to rule them all, or a
> key for each machine?

It's one key for each device account which you want to be able to log on
to your network. That way if a device gets lost you can remove it's key
to prevent access, but all the other keys remain valid and can still be
used.

---druck

On 31/01/2024 20:26, Pancho wrote:
> Yes, I understand the need for unique keys for clients which operate
> outside the home, like a laptop, but what about for the LAN only
> devices? For instance, a rPi using scp to another rPi. I have quite a
> few Pis.
>
> When I set up a new machine, it is often easier to use an existing key
> which already has been installed on all SSH servers, so I use a single
> one. Often, I just copy the ~/.ssh folder. I suppose I could reuse a
> currently unused key from a pool of configured keys, but it seems like a
> lot of work.

Very bad practice. Generate a new key on each device with ssh-keygen and
copy it to your primary machine with ssh-copy-id Then replicate the
primary machines .ssh/authorized_keys file to all the others, so you can
login from any machine to any other.

---druck

On 1/31/24 2:47 AM, Ahem A Rivet's Shot wrote:
> On Tue, 30 Jan 2024 22:43:16 -0500
> "68g.1499" <68g.1499@etr6.net> wrote:
>
>> I'll still say the greatest risk is not hackers, but
>> USERS. They fall for all the tricks and install evilware
>> themselves.
>
> This is standard wisdom in the security game. Simulated phishing
> attacks are common in the workplace now - fall for one and get sent on a
> course, report one and get congratulated. Pity about the giveaway header
> they all carry.

Every time someone sent me a note about smelly e-mail I'd
look through the html/js for telltale signs and often
investigate links (some were to legit entities like PayPal
but with a defective reference number - and then you were
supposed to use an alt address or even call (one call for
a supposedly local US company was actually a Turkish phone#).

Found a few with links to what WAS a legit company wanting
us to check into an invoice - but the company was a mining-
equipment rental company, in Australia.

Another good question is to ask "Does anyone remember EVER
doing business with these people ?". Often it was "No".

Sometimes the evil is hidden as attached Word dox or Excel
spreadsheets or links to same - with lots of interesting
macros. Best research is done with LibreOffice - and DON'T
enable any macros. Incompatibility has its uses.

Anyway, they can be VERY sneaky and the rank and file often
just click by reflex. A "security validation" page wanting
to know a bunch of usernames/passwords/ss# and such, well,
that seems legit/safe, doesn't it ? :-)

My practice was to write a couple paragraph exposition
of exactly WHY a mail was evil and send it to all those
who routinely "did business" in the office. Kept the
tech level low, but just enough. These kinda paid off
in 'sensitizing' them to what's smelly. Is the mail
from some odd entity ? Is it very unclear about WHAT
we're supposed to have purchased/paid ? Odd spelling
or grammar errors ? No such employee ? Long links to
Who-Knows-What ? They DID get better at it.

Thing is, M$ or any other entity you're paying
CANNOT spot all these 'human factors' tricks.
They might spot 'common' ones with kinda fixed
source addresses, but that's about it. Not really
a shield, more a sieve.

Oh, found this today :

https://www.dailymail.co.uk/sciencetech/article-13029089/Notorious-Russia-gang-claims-stole-classified-secret-documents-intelligence-agencies-FBI-warns-China-hackers-preparing-wreak-havoc-America.html

These people work their way into the tippy-top systems, and
often by exploiting "human factors". The SolarWinds hack was
also brilliant - and took awhile to notice - because it took
a sort of indirect path, via a 'trusted vendor' for lower-
level sys-management stuff, rather than a frontal attack.

It's a problem.

It's getting worse, fast.

And there's just no decent replacement for e-mail for biz
purposes. We demand receipts, tracking info, mails in
case of problems, mails for bills. Doesn't matter if
the mail agent is on yer PC or something online, the
evil can still getcha. Back to snail-mail ? Ain't gonna
happen now.

Linux/Unix can be configured to be fairly resistant to
"traditional hacking" - but every user is a serious
vulnerability, by multiple approaches.

Hmmm ... sounds like those abovementioned "top secret
documents" weren't even encrypted - the group KNEW what
it had to bargain with. Oh, it WILL pass the stuff along
to Vlad whether you pay 'em or not - patriotic duty !

On 1/30/24 6:05 PM, Scott Alfter wrote:
> In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
> Chris Green <cl@isbd.net> wrote:
>> I can't us Pi Imager because it's very broken on Ubuntu:-
>
> Sounds like something you should take up with the Ubuntu packagers. I
> maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo eselect
> repository enable salfter && sudo emaint sync -r salfter), and it works like
> a champ.
>
> More recently, I've migrated my print server (an ancient RPi Model B) from
> Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless. The
> Alpine install needed to be done on a spare Raspberry Pi, but once it was up
> and running with ssh access, I was able to do the rest of the setup over the
> network. Once I had it configured as I wanted it, I brought the MicroSD card
> over to another computer to image it and shipped the image home so I could
> blast it onto an SD card. It's a much lighter-weight system now...could put
> it on a 128MB SD card, if I had one that small. :) The server runs headless,
> with just two printers, a network cable, and a power supply plugged in.

Ok ... I'm not gonna ask why you'd want a completely separate
print server, based on an old Pi, rather than just printing
directly from/to whatever :-)

In any case, the "headless" problem is more of a problem
with RP-OS based on Worm. They completely changed how the
networking was done, and while there IS a CL command
with lots of obscure params it's just not as straight-up as
it used to be. I posted info on where to look and templates
for customizable network defs in order to speed people
along in this aspect. Alas that's not the only thing Worm
has pointlessly messed-up. Oh, and BullsEye won't run on
a Pi-5 - you get a testy little message on boot.

Normally I rec RP-OS because it's probably best-tuned to
the boards, easiest tweaking for all the little devices
and pins and such. But NOW ... maybe some ARE better off
with 3rd-party systems depending. Arch, G2, even Fedora
derivs, may be more friendly for "headless". Can't really
rec RHEL derivs anymore since IBM ruined it all, don't
want to build critical stuff on beta (or worse) code.

Theo <theom+news@chiark.greenend.org.uk> wrote:
> Chris Green <cl@isbd.net> wrote:
> > I don't disagreee with what you're saying but there's a load of
> > configuration to do it all if, as is often the case, I'm rebuilding a
> > Raspberry Pi for example.
>
> On your machine:
>
> ssh-copy-id pi@raspberrypi
>
> On the Pi:
> echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/10-passwordauth.conf
> ; sudo service ssh reload
>
> That's it. Two lines.
>
> > "If you never send the password there's nothing to keylog or
> > phish" Ay? If there's a keylogger on your system it doesn't care
> > whether you're typing a password or a key. If it's logging what's
> > sent over the wire then it's encrypted.
>
> The keylogger is often in a compromised SSH daemon on the server, rather
> than in your machine. You connect to the server, it sees your password as
> you type it, it records your password and tries to login to other machines
> using it.
>
> With keys, you never send the private key or passphrase over the connection.
> You tell your SSH client which key to use (or it tries several). The SSH
> client asks you for the passphrase to unlock the key (which is happening
> locally). You tell teh server which key you're using and it checks your
> authorized_keys for that public key.
>
> The site sends you a challenge based on the public key, you compose a
> response to your challenge using the private key, you send the response.
> If the server can decrypt the response you are in possession of the private
> key and the server proceeds to generate keys for this session.
>
> If the keylogger is on your machine, it can get the passphrase but it
> doesn't get the private key unless it is specifically designed for attacking
> ssh and can read your private keys. eg you might see the following in the
> keylog:
>
> ssh chris@server.bigcorp.com
> abr@cad4bra
> ls
>
> and it's clear that abr@cad4bra is your password. If that was your
> passphrase it wouldn't help attack anyone.
>
Not true, you're advocating separate keys for each remote and not
keeping thenm in an agent so login isn't 'passwordless' or automatic.

Thus, when I login I see:-

chris@esprimo$ ssh backup
Enter passphrase for key '/home/chris/.ssh/backup_id_rsa':
chris@backup$

.... the keylogger will see 'ssh backup' followed by the passphrase.

> > You **have** to start with password authentication so it's inevitably
> > there when you start with your headless Pi. Everything more to move
> > to one key per remote system is extra hassle which I have to repeat
> > when I rebuild the Pi (which can be quite frequently, e.g. two or
> > three times in a week).
>
> You don't have to start with password auth. rpi-imager will allow you to
> install a public key into the Pi so you can SSH directly using keys. It
> will also remember your settings so every time you flash a Pi, it gets your
> keys automatically.
>
Yes, I'd forgotten that I must admit, I may start doing it in fact as
using rpi-imager is becoming more necessary anyway.

> > So generate key (OK, that's only once per physical system), copy the
> > key to the remote using ssh-copy-id. Then go to the remote and edit
> > /etc/ssh/sshd_config, then reboot and check it all works. Not a load
> > of work but enough to be a bit of a pain, plus I like to record
> > configuration changes (like the sshd_config one).
>
> etckeeper will keep track of changes to /etc in a git repo
>
I use Mercurial.

> If you want to do this to a lot of machines, it's worth learning Ansible as
> it'll keep your fleet of machines in sync. Just write an ansible recipe
> and it will ensure it is applied (and only once) across all your
> machines.
>
I may take a look, though I already have a common Mercurial repository
where I keep everything like .bashrc, .profile, .ssh/config and so on.
The Mercurial repository is shared across systems using syncthing.

--
Chris Green
·

On 31/01/2024 21:25, druck wrote:
> On 31/01/2024 20:26, Pancho wrote:
>> Yes, I understand the need for unique keys for clients which operate
>> outside the home, like a laptop, but what about for the LAN only
>> devices? For instance, a rPi using scp to another rPi. I have quite a
>> few Pis.
>>
>> When I set up a new machine, it is often easier to use an existing key
>> which already has been installed on all SSH servers, so I use a single
>> one. Often, I just copy the ~/.ssh folder. I suppose I could reuse a
>> currently unused key from a pool of configured keys, but it seems like
>> a lot of work.
>
> Very bad practice. Generate a new key on each device with ssh-keygen and
> copy it to your primary machine with ssh-copy-id Then replicate the
> primary machines .ssh/authorized_keys file to all the others, so you can
> login from any machine to any other.
>

Yes, but in practice that meant everytime I installed a new OS on an
experimental Orange Pi5 I had to alter the set up of seven or eight
machines. Sometimes I was doing this a few times a day.

So I guess my point was, in the real world, many of us implement sub
optimal security on our home LAN. I recognise that I am sloppy, but I
think I should be careful to prioitorise security measures that improve
the most glaring security holes, without impeeding usability.

Sometimes people are religous about security, hypocritically claiming
they never sin, when they do, for pragmatic reasons. In the past I have
worked for large prestigous companies that had the most astonishing
security loopholes.

Off the top of my head I have always thought a SSH passphrase and SSH
agent might be the best first step. However I really am quite naive so
any advice is appreciated.

On 31/01/2024 21:18, druck wrote:
> On 30/01/2024 23:35, Pancho wrote:
>> I find it useful to have a weak point, one machine with password
>> authentication, for that time I find myself on a machine without an
>> appropriate key.
>
> That's handy - for miscreants. I assume from that machine you can log in
> to other machines on your network? If so they will be able too.
>

Not neccessarily, I could use a passphrase or different username. Which
might not be obvious to an attacker.

However I think if the are on the machine in the first palce I'm in deep
shit.

Pancho <Pancho.Jones@proton.me> writes:
> On 31/01/2024 21:25, druck wrote:
>> On 31/01/2024 20:26, Pancho wrote:
>>> Yes, I understand the need for unique keys for clients which
>>> operate outside the home, like a laptop, but what about for the LAN
>>> only devices? For instance, a rPi using scp to another rPi. I have
>>> quite a few Pis.
>>>
>>> When I set up a new machine, it is often easier to use an existing
>>> key which already has been installed on all SSH servers, so I use a
>>> single one. Often, I just copy the ~/.ssh folder. I suppose I could
>>> reuse a currently unused key from a pool of configured keys, but it
>>> seems like a lot of work.
>> Very bad practice. Generate a new key on each device with ssh-keygen
>> and copy it to your primary machine with ssh-copy-id Then replicate
>> the primary machines .ssh/authorized_keys file to all the others, so
>> you can login from any machine to any other.
>
> Yes, but in practice that meant everytime I installed a new OS on an
> experimental Orange Pi5 I had to alter the set up of seven or eight
> machines. Sometimes I was doing this a few times a day.

You’ve got several reasonable options:

1) Review your requirements. Do you really need everything to be able to
talk to everything? If not then some of those alterations are wasted.

2) Automate the process of copying new public keys all the places they
need to be. Computers are better than you are repetitive tasks.

3) Use certificate-based authentication. Instead of copying public keys
everywhere, just sign them once, and get each endpoint to trust the
CA.

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

"68g.1499" <68g.1499@etr6.net> writes:
> Similar experiences here too and more like 15 years. They always
> seem to use a list of "common usernames" and another list of
> "common passwords". The 'smartest' one used some names from
> the company e-mail acct. In short, all script kiddies - bots -
> no pro/State-level stuff. Sorry to burst many egos, but really
> is YOUR server WORTH five CPU-seconds by N.Korea ???

One compromised host is worth relatively little, but nobody compromises
just one host.

- Even a small amount of CPU is worth putting a cryptocurrency miner on,
for someone who has automated the process of stealing access.

- Fleets of hacked computers are used in DDoS attacks.

- Individual hacked computer make good jumping off points to obscure the
true origin of attacks of any kind.

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

On 2024-01-31, The Natural Philosopher wrote:

> On 31/01/2024 16:02, Adam Funk wrote:
>> On 2024-01-30, The Natural Philosopher wrote:
>>
>>> On 30/01/2024 06:03, 68g.1499 wrote:
>>>> The continuing most-dangerous thing out there is not "hacking" but
>>>> "human factors" -
>>>
>>> My chief engineer went to do a security audit and install a corporate
>>> firewall, and then test it.
>>>
>>> His security report included:
>>>
>>> - "The widespread use of dial in modems connecting to users DDI ports to
>>> enable them to operate their windows desktop computers from home
>>> represents a far greater security risk than that offered by the internet
>>> connection....
>>
>> How long ago was that?
>>
> 1997 or something?

OK, that's not so surprising.

On 01/02/2024 06:32, 68g.1499 wrote:
> On 1/30/24 6:05 PM, Scott Alfter wrote:
>> In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
>> Chris Green  <cl@isbd.net> wrote:
>>> I can't us Pi Imager because it's very broken on Ubuntu:-
>>
>> Sounds like something you should take up with the Ubuntu packagers.  I
>> maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo
>> eselect
>> repository enable salfter && sudo emaint sync -r salfter), and it
>> works like
>> a champ.
>>
>> More recently, I've migrated my print server (an ancient RPi Model B)
>> from
>> Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless.  The
>> Alpine install needed to be done on a spare Raspberry Pi, but once it
>> was up
>> and running with ssh access, I was able to do the rest of the setup
>> over the
>> network.  Once I had it configured as I wanted it, I brought the
>> MicroSD card
>> over to another computer to image it and shipped the image home so I
>> could
>> blast it onto an SD card.  It's a much lighter-weight system
>> now...could put
>> it on a 128MB SD card, if I had one that small. :) The server runs
>> headless,
>> with just two printers, a network cable, and a power supply plugged in.
>
>
>   Ok ... I'm not gonna ask why you'd want a completely separate
>   print server, based on an old Pi, rather than just printing
>   directly from/to whatever   :-)
>
It avoids massively long printer cables obviously, when you have a
pre-existent network of some sort...

r worse) code.
>

--
“There are two ways to be fooled. One is to believe what isn’t true; the
other is to refuse to believe what is true.”

—Soren Kierkegaard

In article <zQKdnaXu1ZFtpyb4nZ2dnZfqn_udnZ2d@earthlink.com>,
68g.1499 <68g.1499@etr6.net> wrote:
>On 1/30/24 6:05 PM, Scott Alfter wrote:
>> In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
>> Chris Green <cl@isbd.net> wrote:
>>> I can't us Pi Imager because it's very broken on Ubuntu:-
>>
>> Sounds like something you should take up with the Ubuntu packagers. I
>> maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo eselect
>> repository enable salfter && sudo emaint sync -r salfter), and it works like
>> a champ.
>>
>> More recently, I've migrated my print server (an ancient RPi Model B) from
>> Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless. The
>> Alpine install needed to be done on a spare Raspberry Pi, but once it was up
>> and running with ssh access, I was able to do the rest of the setup over the
>> network. Once I had it configured as I wanted it, I brought the MicroSD card
>> over to another computer to image it and shipped the image home so I could
>> blast it onto an SD card. It's a much lighter-weight system now...could put
>> it on a 128MB SD card, if I had one that small. :) The server runs headless,
>> with just two printers, a network cable, and a power supply plugged in.
>
>
> Ok ... I'm not gonna ask why you'd want a completely separate
> print server, based on an old Pi, rather than just printing
> directly from/to whatever :-)

The printers in question (an HP LaserJet 1320 and a Zebra LP2844) don't have
built-in network connectivity. The print server is basically a
JetDirect-compatible box that receives print data on one port for one
printer and on another port for the other. I have an actual, rather old HP
JetDirect print server in a box somewhere. It's in a box because its
10-Mbps Ethernet on one end and USB 1.x on the other is a bit slow for
complex print jobs. Fast Ethernet (100 Mbps) and USB 2.0 on the Raspberry
Pi is a step up.

--
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

On 01/02/2024 16:29, Scott Alfter wrote:
> In article <zQKdnaXu1ZFtpyb4nZ2dnZfqn_udnZ2d@earthlink.com>,
> 68g.1499 <68g.1499@etr6.net> wrote:
>> On 1/30/24 6:05 PM, Scott Alfter wrote:
>>> In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
>>> Chris Green <cl@isbd.net> wrote:
>>>> I can't us Pi Imager because it's very broken on Ubuntu:-
>>>
>>> Sounds like something you should take up with the Ubuntu packagers. I
>>> maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo eselect
>>> repository enable salfter && sudo emaint sync -r salfter), and it works like
>>> a champ.
>>>
>>> More recently, I've migrated my print server (an ancient RPi Model B) from
>>> Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless. The
>>> Alpine install needed to be done on a spare Raspberry Pi, but once it was up
>>> and running with ssh access, I was able to do the rest of the setup over the
>>> network. Once I had it configured as I wanted it, I brought the MicroSD card
>>> over to another computer to image it and shipped the image home so I could
>>> blast it onto an SD card. It's a much lighter-weight system now...could put
>>> it on a 128MB SD card, if I had one that small. :) The server runs headless,
>>> with just two printers, a network cable, and a power supply plugged in.
>>
>>
>> Ok ... I'm not gonna ask why you'd want a completely separate
>> print server, based on an old Pi, rather than just printing
>> directly from/to whatever :-)
>
> The printers in question (an HP LaserJet 1320 and a Zebra LP2844) don't have
> built-in network connectivity. The print server is basically a
> JetDirect-compatible box that receives print data on one port for one
> printer and on another port for the other. I have an actual, rather old HP
> JetDirect print server in a box somewhere. It's in a box because its
> 10-Mbps Ethernet on one end and USB 1.x on the other is a bit slow for
> complex print jobs. Fast Ethernet (100 Mbps) and USB 2.0 on the Raspberry
> Pi is a step up.
>

Yeah I had one of those for a big A1 plotter.
Pi is a great idea for a print server.

--
If you tell a lie big enough and keep repeating it, people will
eventually come to believe it. The lie can be maintained only for such
time as the State can shield the people from the political, economic
and/or military consequences of the lie. It thus becomes vitally
important for the State to use all of its powers to repress dissent, for
the truth is the mortal enemy of the lie, and thus by extension, the
truth is the greatest enemy of the State.

Joseph Goebbels