It is now very nearly impossible to install a headless Pi

[Chris Green]

I am getting very frustrated by stupid 'security'. I simply want to
install a new OS on a headless Pi and it's very close to impossible.

I first tried to download an image and install it. OK, it works but I
can't log in because ther eis no longer a default user/password there
even though I have enabled ssh.

I can't us Pi Imager because it's very broken on Ubuntu:-

root@t470# dpkg -i ./imager_1.8.5_amd64.deb
Selecting previously unselected package rpi-imager.
(Reading database ... 274950 files and directories currently installed.)
Preparing to unpack ./imager_1.8.5_amd64.deb ...
Unpacking rpi-imager (1.8.5) ...
dpkg: dependency problems prevent configuration of rpi-imager:
rpi-imager depends on qml-module-qtquick2; however:
Package qml-module-qtquick2 is not installed.
rpi-imager depends on qml-module-qtquick-controls2; however:
Package qml-module-qtquick-controls2 is not installed.
rpi-imager depends on qml-module-qtquick-layouts; however:
Package qml-module-qtquick-layouts is not installed.
rpi-imager depends on qml-module-qtquick-templates2; however:
Package qml-module-qtquick-templates2 is not installed.
rpi-imager depends on qml-module-qtquick-window2; however:
Package qml-module-qtquick-window2 is not installed.
rpi-imager depends on qml-module-qtgraphicaleffects; however:
Package qml-module-qtgraphicaleffects is not installed.

dpkg: error processing package rpi-imager (--install):
dependency problems - leaving unconfigured
Processing triggers for gnome-menus (3.36.0-1.1ubuntu1) ...
Processing triggers for desktop-file-utils (0.26-1ubuntu5) ...
Processing triggers for mailcap (3.70+nmu1ubuntu1) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for man-db (2.11.2-3) ...
Errors were encountered while processing:
rpi-imager


For goodness sake what awful earth shattering disasters are going to
occur if I do create a Pi installation with default username and
password?

This is getting &(^(^$^&(*^^$&^^%(* ridiculous!!!!!!!


--
Chris Green
·

[Computer Nerd Kev]

Chris Green <c...@isbd.net> wrote:
> I am getting very frustrated by stupid 'security'. I simply want to
> install a new OS on a headless Pi and it's very close to impossible.
>
> I first tried to download an image and install it. OK, it works but I
> can't log in because ther eis no longer a default user/password there
> even though I have enabled ssh.
>
> I can't us Pi Imager because it's very broken on Ubuntu:-

There is a way to set a user up in a "userconf.txt" file described
here:
https://www.raspberrypi.com/documentation/computers/configuration.html#remote-access

Another option would be to copy the /etc/passwd, /etc/shadow, and
/etc/group files from a similar existing RPi system while the OS
file system on the SD card is mounted at a Linux PC. Or you could
edit them manually and even create a user who doesn't need a
password at all.

> For goodness sake what awful earth shattering disasters are going to
> occur if I do create a Pi installation with default username and
> password?
>
> This is getting &(^(^$^&(*^^$&^^%(* ridiculous!!!!!!!

I agree, they're trying too hard to save users from themselves in
case someone leaves their RPi open to incoming SSH connections on
the internet. But most obviously won't do that.

--
__ __
#_ < |\| |< _# | Note: I won't see posts made from Google Groups |

[Bryan]

It would be easy enough to force the user to change the password at
first boot, that's what some of the other distributions for SBCs do.
Armbian, in particular, gives you root at boot but you have to set a
password that isn't the default "1234".

Removing the user altogether seems to be the nuclear option, especially
if you got used to setting up headless devices.

[Theo]

Chris Green <c...@isbd.net> wrote:
> I am getting very frustrated by stupid 'security'. I simply want to
> install a new OS on a headless Pi and it's very close to impossible.
>
> I first tried to download an image and install it. OK, it works but I
> can't log in because ther eis no longer a default user/password there
> even though I have enabled ssh.
>
> I can't us Pi Imager because it's very broken on Ubuntu:-

Does:

$ sudo apt install rpi-imager

not work for you?

It's been in Ubuntu since 22.04, possibly before that.

There is also

$ sudo snap install rpi-imager

which comes from https://github.com/waveform80/imager-snap/

> For goodness sake what awful earth shattering disasters are going to
> occur if I do create a Pi installation with default username and
> password?

Well, if you put that on the internet you're in for trouble.

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

You are free to write the image to SD and then mount it and edit /etc/passwd
and /etc/shadow to change the login user/password if you so desire.

Theo

[Jim Jackson]

> There is a way to set a user up in a "userconf.txt" file described
> here:
> https://www.raspberrypi.com/documentation/computers/configuration.html#remote-access
>
> Another option would be to copy the /etc/passwd, /etc/shadow, and
> /etc/group files from a similar existing RPi system while the OS
> file system on the SD card is mounted at a Linux PC. Or you could
> edit them manually and even create a user who doesn't need a
> password at all.

Or set up an ~userid/.ssh/authorized_keys file, with sshd enabled

[Lawrence D'Oliveiro]

On Fri, 26 Jan 2024 19:52:20 +0000, Chris Green wrote:

> I can't us Pi Imager because it's very broken on Ubuntu:-
>
> root@t470# dpkg -i ./imager_1.8.5_amd64.deb Selecting previously

> ...
> dpkg: dependency problems prevent configuration of rpi-imager:

> ...

That’s not “broken”. dpkg is a very low-level tool that only knows how to
install the .deb files you specify to it. Either explicitly download and
install the extra ones it says it needs, or if you want automatic
dependency resolution, you need the higher-level “apt-get” command.

UTRTFTJ.

[Chris Green]

OP here, that's actually quite a neat way to do it. I use ssh a lot
(with and without key authorisation) so it wouldn't be too difficult.

--
Chris Green
·

[Chris Green]

Computer Nerd Kev <n...@telling.you.invalid> wrote:
> Chris Green <c...@isbd.net> wrote:
> > I am getting very frustrated by stupid 'security'. I simply want to
> > install a new OS on a headless Pi and it's very close to impossible.
> >
> > I first tried to download an image and install it. OK, it works but I
> > can't log in because ther eis no longer a default user/password there
> > even though I have enabled ssh.
> >
> > I can't us Pi Imager because it's very broken on Ubuntu:-
>
> There is a way to set a user up in a "userconf.txt" file described
> here:
> https://www.raspberrypi.com/documentation/computers/configuration.html#remote-access
>

Yes, I did find that, but it is messy having to create hashed entries
etc.

> Another option would be to copy the /etc/passwd, /etc/shadow, and
> /etc/group files from a similar existing RPi system while the OS
> file system on the SD card is mounted at a Linux PC. Or you could
> edit them manually and even create a user who doesn't need a
> password at all.
>

I did try that, or at least I thought I had created a user with no
password but it didn't work. I may have been getting a bit frustrated
by then though so it's quite likely I got something wrong.

> > For goodness sake what awful earth shattering disasters are going to
> > occur if I do create a Pi installation with default username and
> > password?
> >
> > This is getting &(^(^$^&(*^^$&^^%(* ridiculous!!!!!!!
>
> I agree, they're trying too hard to save users from themselves in
> case someone leaves their RPi open to incoming SSH connections on
> the internet. But most obviously won't do that.
>

In the end I managed to install rpi-imager, it's in the Ubuntu
repositories now so installing it from there brings in all the missing
dependencies I saw.

--
Chris Green
·

[Chris Green]

Theo <theom...@chiark.greenend.org.uk> wrote:
> Chris Green <c...@isbd.net> wrote:
> > I am getting very frustrated by stupid 'security'. I simply want to
> > install a new OS on a headless Pi and it's very close to impossible.
> >
> > I first tried to download an image and install it. OK, it works but I
> > can't log in because ther eis no longer a default user/password there
> > even though I have enabled ssh.
> >
> > I can't us Pi Imager because it's very broken on Ubuntu:-
>
> Does:
>
> $ sudo apt install rpi-imager
>
> not work for you?
>
> It's been in Ubuntu since 22.04, possibly before that.
>
> There is also
>
> $ sudo snap install rpi-imager
>
> which comes from https://github.com/waveform80/imager-snap/
>
> > For goodness sake what awful earth shattering disasters are going to
> > occur if I do create a Pi installation with default username and
> > password?
>
> Well, if you put that on the internet you're in for trouble.
>

Who puts a 'naked' Raspberry Pi on the internet? 99.999% of them will
either be stand-alone systems not connected to anything or will be on
a home LAN behind NAT and a firewall.

Yes, I did find I could install rpi-imager from the Ubuntu
repositories, that's how I managed to get installed in the end.

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

How about no password, would that be OK? :-)

--
Chris Green
·

[Theo]

Chris Green <c...@isbd.net> wrote:

> Theo <theom...@chiark.greenend.org.uk> wrote:
> >
> Who puts a 'naked' Raspberry Pi on the internet? 99.999% of them will
> either be stand-alone systems not connected to anything or will be on
> a home LAN behind NAT and a firewall.

According to Shodan there are 22,700 systems claiming to be 'Raspbian' on
the internet.

Also, even if the Pi is firewalled, there is a threat from other users of
the LAN including compromised machines. You only need one machine to be
compromised to allow attackers into the network and then they can search out
for vulnerable machines from there.

If your network only has you, yourself and I, this is a different threat
from say a school where there are potentially many machines out of your
control.

> Yes, I did find I could install rpi-imager from the Ubuntu
> repositories, that's how I managed to get installed in the end.

OK, so your thread title is inaccurate.

> > More to the point it's now illegal to have default usernames and passwords
> > in the UK, so the RPi folks have to comply.
> >
> How about no password, would that be OK? :-)

It would be illegal to sell something in that state.

Otherwise, it depends on your threat model...

Theo

[TimS]

On 26 Jan 2024 at 22:14:59 GMT, "Theo" <theom...@chiark.greenend.org.uk>
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.

Wot? No more FIELD/SERVICE? How will we cope?

--
Tim

[Ahem A Rivet's Shot]

On Sat, 27 Jan 2024 07:34:51 +0000
Chris Green <c...@isbd.net> wrote:

> Who puts a 'naked' Raspberry Pi on the internet?

I used to use one as a router originally with a USB ethernet
and later using VLANs and a managed switch, not since I got FTTH though. It
was running FreeBSD though.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
For forms of government let fools contest
Whate're is best administered is best - Alexander Pope

[Lawrence D'Oliveiro]

DEC/VMS joke. I think. ;)

[Richard Falken]

Re: It is now very nearly impossible to install a headless Pi
By: Chris Green to All on Fri Jan 26 2024 07:52 pm

> I am getting very frustrated by stupid 'security'. I simply want to
> install a new OS on a headless Pi and it's very close to impossible.
>

You have just reminded me of this article about autmated RPi headless
deployments, but I don't know if it still applies:

https://www.linux-magazine.com/Issues/2020/235/BerryLan

--
gopher://gopher.richardfalken.com/1/richardfalken

[68g.1499]

On 1/26/24 5:14 PM, 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.
>

On install, you CAN select 'pi' as the username and anything
you want as the password. It WILL complain - but will do it
if you demand. If you change passwords later there's more of
a chance it will demand "minimum complexity" (that's deep in
the PAM stuff).

IMHO, the more important bit is the password, not the user name.
Make 'em a bit strange and not TOO damned short. A guy in my
office used to use "." as his Winders password :-)

Saw little article today ... "qwerty123" has become almost
as nefarious as "password"

Now if you're a bank or e-commerce site or something higher
profile then yea, gotta get more complicated and add
fail2ban and some other stuff for sure. North Korea is not
going to spend five days worth of CPU time to crack your
little home Pi and its valuable horde of "Rick and Morty"
vids. Your home connection is likely too slow to be very
useful for launching broadscale attacks on other systems
as well.

[The Natural Philosopher]

On 29/01/2024 04:54, 68g.1499 wrote:
> North Korea is not
>   going to spend five days worth of CPU time to crack your
>   little home Pi and its valuable horde of "Rick and Morty"
>   vids. Your home connection is likely too slow to be very
>   useful for launching broadscale attacks on other systems
>   as well.

Indeed. I've two servers on the open internet with open ssh ports . In 8
years although there is a constant stream of login attempts no one has
guessed the correct user name - let alone the password.

People get paranoid about stuff they think they know about and forget
the simple things.
A long but easily memorable string like my.cat.hates.PIZZA! will
probably fall to a dictionary attack in a few thousand hours, but
really, who cares?

Sorry, you are not that important, and neither am I.


--
“The urge to save humanity is almost always only a false face for the
urge to rule it.”
– H. L. Mencken

[Chris Green]

The Natural Philosopher <t...@invalid.invalid> wrote:
> On 29/01/2024 04:54, 68g.1499 wrote:
> > North Korea is not
> >   going to spend five days worth of CPU time to crack your
> >   little home Pi and its valuable horde of "Rick and Morty"
> >   vids. Your home connection is likely too slow to be very
> >   useful for launching broadscale attacks on other systems
> >   as well.
>
> Indeed. I've two servers on the open internet with open ssh ports . In 8
> years although there is a constant stream of login attempts no one has
> guessed the correct user name - let alone the password.
>
> People get paranoid about stuff they think they know about and forget
> the simple things.
> A long but easily memorable string like my.cat.hates.PIZZA! will
> probably fall to a dictionary attack in a few thousand hours, but
> really, who cares?
>

I've never understood how this can work. If you type a wrong password
to ssh it will wait several seconds before allowing you to try again.
In addition it will throw you off completely after three failures and
you'd have to start all over. This is default ssh, no fail2ban or
anything like that.

So how can a dictionary attack possibly work? It would take years!

--
Chris Green
·

[Theo]

Chris Green <c...@isbd.net> wrote:
> I've never understood how this can work. If you type a wrong password
> to ssh it will wait several seconds before allowing you to try again.
> In addition it will throw you off completely after three failures and
> you'd have to start all over. This is default ssh, no fail2ban or
> anything like that.

Bombard the machine with SSH connections. There's no delay (aside from the
CPU overhead) for starting a new connection, so don't bother with the
timeout, just throw as many parallel connections at the machine as you can.
If you get rejected, just terminate the TCP connection and open a new one.
Or just wait out the timeout, with X thousand parallel connections it
doesn't waste any resources doing that.

Next, run it via a botnet so each connection comes from a different IP, so
avoiding fail2ban and similar firewall techniques.

Finally, parallelise over a lot of different victims. Maybe you'll get
lucky at one victim, it's just a matter of probabilities.

> So how can a dictionary attack possibly work? It would take years!

These are often not dictionary attacks in the sense of trying all the
dictionary words (including the d1ct10n4ry w0rds etc), but using lists of
known usernames/passwords. Which you can be sure pi:raspberry is on.

Theo

[The Natural Philosopher]

Not sure how it works, but I see series of attacks spaced about 5
seconds apart. Usually from different IP addresses

>
> So how can a dictionary attack possibly work? It would take years!
>

Well exactly. It's been going on for years!


--
Those who want slavery should have the grace to name it by its proper
name. They must face the full meaning of that which they are advocating
or condoning; the full, exact, specific meaning of collectivism, of its
logical implications, of the principles upon which it is based, and of
the ultimate consequences to which these principles will lead. They must
face it, then decide whether this is what they want or not.

Ayn Rand.

[The Natural Philosopher]

But grumpyOldSod:suckMyDick.57 probably is not...

> Theo

--
"First, find out who are the people you can not criticise. They are your
oppressors."
- George Orwell

[Chris Green]

Well, as I said, at 5 seconds per attempt a dictionary attack is
hopeless.

--
Chris Green
·

[Chris Green]

OK, so it may be slightly more possible than I was surmising. However
a Raspberry Pi isn't that fast, it'll run out of puff quite rapidly!
My B+ takes quite a while just to log me in with password
authentication! :-)

--
Chris Green
·

[Lawrence D'Oliveiro]

On Mon, 29 Jan 2024 12:19:21 +0000, Chris Green wrote:

> So how can a dictionary attack possibly work? It would take years!

Particularly if you don’t allow password-based logins in the first
place ...

[68g.1499]

On 1/29/24 5:00 AM, The Natural Philosopher wrote:
> On 29/01/2024 04:54, 68g.1499 wrote:
>> North Korea is not
>>    going to spend five days worth of CPU time to crack your
>>    little home Pi and its valuable horde of "Rick and Morty"
>>    vids. Your home connection is likely too slow to be very
>>    useful for launching broadscale attacks on other systems
>>    as well.
>
> Indeed. I've two servers on the open internet with open ssh ports . In 8
> years although there is a constant stream of login attempts no one has
> guessed the correct user name  - let alone the password.

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

> People get paranoid about stuff they think they know about and forget
> the simple things.

Well ... there's $$$ in being a doom-sayer. Articles and
'news' (and security-ware vendors) always hype it up.
I get several End-Of-The-World mails from Norton every
single week.

You have to THINK about YOUR place on the hack-worthy
totem pole and THEN act accordingly.

For SSH I never ever use the default port - and that seems
to deter 99.9% of the bots right off. Limit max tries/sessions/
connections and that'll get rid of 99.9% of the remaining.
Movie-style "hacking" is just not WORTH it for home/smallbiz
systems. They go for the BIG stuff - banks/M$/SolarWinds/etc.

> A  long but easily memorable string like  my.cat.hates.PIZZA! will
> probably fall to a dictionary attack in a few thousand hours, but
> really, who cares?

It's OK to use more-obscure dictionary words, just break
it up with a few numbers/characters. 10-12 chars total
is more than bots are interested in trying to figure out.
Anyway, this way YOU can remember it, THEY can't be bothered
trying to work it out.

The continuing most-dangerous thing out there is not "hacking"
but "human factors" - esp mail-based ransomware and to some
degree "click-ware". Humans never look for the ".ru" or
whether the mail "smells right" - they just click the big
shiny link. Those are SO EASY to mass-distribute that if
even 0.05% fall for it they've made their money.

My successor is really really good with GiantCorp package
offerings but I'm afraid he's kinda thin on the skills to
actually analyze/research a smelly e-mail. So long as
he can say it's M$'s fault the nasty thing got through ...

> Sorry, you are not that important, and neither am I.

"Paranoia" is actually a mutant form of EGOTISM ...
where some nobody comes to think THEY are SO
important that giant spectral orgs and States are
gonna spend millions and CPU-years and thousands
of man-hours just to mess around with them.

Then comes the tinfoil wallpaper and hats and lead-
lined underwear... and then proof of conspiracy when
the cell reception gets crappy ...

[druck]

On 29/01/2024 10:00, The Natural Philosopher wrote:
> On 29/01/2024 04:54, 68g.1499 wrote:
>> North Korea is not
>>    going to spend five days worth of CPU time to crack your
>>    little home Pi and its valuable horde of "Rick and Morty"
>>    vids. Your home connection is likely too slow to be very
>>    useful for launching broadscale attacks on other systems
>>    as well.

Your broadband is plenty fast enough to launch DDNS attacks along with
thousands of other compromised systems. It's the sheer number of
compromised machines on a botnet rather than their connection speeds
which makes it a problem.

> Indeed. I've two servers on the open internet with open ssh ports . In 8
> years although there is a constant stream of login attempts no one has
> guessed the correct user name  - let alone the password.

Most of the attempts are against root or known service names, but there
are lots of username/password attempts which have probably come from
other successfully compromised systems, reminding you to never reuse
credentials.

> People get paranoid about stuff they think they know about and forget
> the simple things.
> A  long but easily memorable string like  my.cat.hates.PIZZA! will
> probably fall to a dictionary attack in a few thousand hours, but
> really, who cares?
>
> Sorry, you are not that important, and neither am I.

Your Pi may not be very important, but else can they get to once inside
your network? And do you really want it to be used to attack others?

---druck

[Ahem A Rivet's Shot]

On Tue, 30 Jan 2024 01:03:40 -0500
"68g.1499" <68g....@etr6.net> wrote:

> no pro/State-level stuff. Sorry to burst many egos, but really
> is YOUR server WORTH five CPU-seconds by N.Korea ???

How much is a botnet node worth ? In CPU-seconds ? Or to invert it
how cheaply can they be obtained in CPU-seconds. I prefer that my systems
aren't at the low end of the list but rather far enough up it that the bulk
harvesters won't bother me.

It's like bicycle locks, nothing will stop a determined thief but
any thief will go for the easy ones first so fit something half decent but
don't go over the top.

[The Natural Philosopher]

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

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


I rest your case....


--
In todays liberal progressive conflict-free education system, everyone
gets full Marx.

[The Natural Philosopher]

Indeed. My B is fast because it has SSD, but the Zero takes an age.
--
"I am inclined to tell the truth and dislike people who lie consistently.
This makes me unfit for the company of people of a Left persuasion, and
all women"

[The Natural Philosopher]

On 30/01/2024 10:08, Ahem A Rivet's Shot wrote:
> On Tue, 30 Jan 2024 01:03:40 -0500
> "68g.1499" <68g....@etr6.net> wrote:
>
>> no pro/State-level stuff. Sorry to burst many egos, but really
>> is YOUR server WORTH five CPU-seconds by N.Korea ???
>
> How much is a botnet node worth ? In CPU-seconds ? Or to invert it
> how cheaply can they be obtained in CPU-seconds. I prefer that my systems
> aren't at the low end of the list but rather far enough up it that the bulk
> harvesters won't bother me.
>
> It's like bicycle locks, nothing will stop a determined thief but
> any thief will go for the easy ones first so fit something half decent but
> don't go over the top.
>

Its also like bicycles in that a thief wont spend time on a worthless
kids tricycle. When there is a carbon fibre mountain bike parked next to it.

I literally have nothing of value to a thief anywhere on any system. At
worst, I might lose a small amount of money in a bank account, before
the bank cried 'foul'. Every single financial transaction these days
uses 2FA and and SMS to my smartphone.

They would need both.

And if I lose the smartphone, there are no banking details on it whatsoever.

That's all done from a desktop.

As I said, I personally am simply not worth hacking except as a botnet
member.

I am thank Clapton, supremely unimportant in the grand scheme of things.

[The Natural Philosopher]

Not a lot really.

And I would notice a botnet DDOS attack within seconds. I have a
permanent traffic sensor on every desktop and a web page monitoring
router traffic.
the moment those show anything the browser gets switched off. There are
some sites that will enrol up in peer to peer shit.

I have found two. I assume some javascript action of some sort.

I dont use them any more.


--
There is something fascinating about science. One gets such wholesale
returns of conjecture out of such a trifling investment of fact.

Mark Twain

[druck]

On 30/01/2024 11:45, The Natural Philosopher wrote:
> On 30/01/2024 10:08, Ahem A Rivet's Shot wrote:
>>     How much is a botnet node worth ? In CPU-seconds ? Or to invert it
>> how cheaply can they be obtained in CPU-seconds. I prefer that my systems
>> aren't at the low end of the list but rather far enough up it that the
>> bulk harvesters won't bother me.
>>
>>     It's like bicycle locks, nothing will stop a determined thief but
>> any thief will go for the easy ones first so fit something half decent
>> but don't go over the top.
>>
> Its also like bicycles in that a thief wont spend time on a worthless
> kids tricycle. When there is a carbon fibre mountain bike parked next to
> it.

It's nothing like bicycles, botnet hurders don't care what they are
cracking, adding another node to a botnet is the goal and one is pretty
much as good as another. Also they aren't putting their own effort or
their own CPU cycles into cracking new machines, it's being done by a
script running on other peoples machines already in the botnet.

---druck

[Scott Alfter]

In article <k4fd8k-d...@esprimo.zbmc.eu>,

Chris Green <c...@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.

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

[Scott Alfter]

In article <-FadnQKrpYU-sir4...@earthlink.com>,

68g.1499 <68g....@etr6.net> wrote:
> On install, you CAN select 'pi' as the username and anything
> you want as the password. It WILL complain - but will do it
> if you demand. If you change passwords later there's more of
> a chance it will demand "minimum complexity" (that's deep in
> the PAM stuff).

For remote access (to a headless box or otherwise), you should be using
key-based authentication anyway and should disable password authentication
in sshd.

[Pancho]

On 30/01/2024 23:16, Scott Alfter wrote:
> In article <-FadnQKrpYU-sir4...@earthlink.com>,
> 68g.1499 <68g....@etr6.net> wrote:
>> On install, you CAN select 'pi' as the username and anything
>> you want as the password. It WILL complain - but will do it
>> if you demand. If you change passwords later there's more of
>> a chance it will demand "minimum complexity" (that's deep in
>> the PAM stuff).
>
> For remote access (to a headless box or otherwise), you should be using
> key-based authentication anyway and should disable password authentication
> in sshd.
>

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.

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

[Scott Alfter]

In article <upc13i$16fsg$1...@dont-email.me>,

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

[68g.1499]

Doesn't hurt to run a few utils like top and htop and ps
every so often. Bots use cpu, memory and bandwidth. Some
might do a fair job at disguise, others won't do so well.
Simply re-booting, like a cron job at midnight, may be
enough to mess up their function.

"Popular" systems - Win/Android/Mac - are going to be the
primary targets, bots and such optimized for them. Linux
proper is there, but not super-popular by the percentages.
Win in particular is a security disaster and most users
are know-nothings, best to put efforts there.

"Perfect" security does not exist, not even for mega-corps
or federal/defense systems. Automated defenses are always
behind the curve - the attackers always have the advantage.
BUT - attackers DO want a decent investment/return picture
and infesting my old C-64 or even my Pi-2 is not a good
investment. Low exposure is also a priority for bots, if
they show up everywhere then there will be detections and
automatic responses made and the useful life of the bot will
be short. In short, there's an economy to it to achieve
maximum bang/buck.

Philosopher is almost TOO extreme, loses a lot of utility
in order to be safe. That's his call. I'd like to be THAT
stealthy, THAT much of a cyberverse ghost, but can't quite
go that far (yet).

I'll still say the greatest risk is not hackers, but
USERS. They fall for all the tricks and install evilware
themselves.

[68g.1499]

On 1/30/24 6:37 AM, 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....
>
> -  "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...
>
>
> I rest your case....

Heh, heh ... :-)

Though dial-up modems are kinda yesterdecade (did find a new
one still it its wrapped box under a desk when I cleaned out
my office recently though)

A very REAL prob, which persists, is that more than one
person often has to know connection usernames/passwords/
ports/etc no matter the methods. Multiple users may need
to access each others data when "Mr. X" goes on vacation.
You also cannot have just ONE super-duper 'vault' for said
docs because redundancy is safety.

Redundancy is also vulnerability - it's a
trade-off. You have to keep that "list on the wall" in
more than one location - and you'll NEVER be sure some
functionary didn't copy it into a Word doc in their
Documents folder (the first thing intruders go at) for
convenience.

No malice is required, simply normal human,
inevitable, laziness. Could NOT do manual log-in to use
network shares or 2FA or anything else nastily inconvenient
at my old job - the staff wouldn't put up with it. Had
to be fairly easy, automatic. Human nature and the truth of
the cyberverse are often at odds - and the whiners win.

Best I could do was to allow no "home-worker" RDT type
connections. Be there or be square. No 'active directory'
or any other Win single-point auto-"update"-ware either.
Many who did that stuff suffered horribly ; my "primitive"
approach was closer to indestructible - evilware had
few paths.

The new IT people, they really go for all that M$
convenience stuff - cloud networking, systemwide
updates, remote-workers, no linux/unix master
boxes, 3rd-party 'security monitoring', Online 365,
PROMISED secure cloud storage/backups, all that
"great" stuff. Probably not a single on-site backup.
I used to pre-encrypt anything sent to cloud backup.
They won't - they'll trust M$ or whomever.

Given the increasingly nasty world situation, I figure
six months before NK or some Romanian ransomware kiddies
blast it all to oblivion. Oh well, I'm out, getting my
pension ... whatever will be will be. Nobody seems to
learn anything ..........

[Chris Green]

Scott Alfter <sc...@alfter.diespammersdie.us> wrote:
> In article <-FadnQKrpYU-sir4...@earthlink.com>,
> 68g.1499 <68g....@etr6.net> wrote:
> > On install, you CAN select 'pi' as the username and anything
> > you want as the password. It WILL complain - but will do it
> > if you demand. If you change passwords later there's more of
> > a chance it will demand "minimum complexity" (that's deep in
> > the PAM stuff).
>
> For remote access (to a headless box or otherwise), you should be using
> key-based authentication anyway and should disable password authentication
> in sshd.
>

Why specifically?

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.

I *could* generate a separate key for every remote and force it to ask
for the key every time I log in but that adds extra hassle every time
I add or change a remote system.

Using the default (ssh password authentication) means that I have no
extra configuration required to either default or local system **and**
no on can casually walk up to desktop or laptop and get a login to a
remote.

Yes, a key is harder to crack than a password, but a reasonably
difficult to guess password is going to take far too long (in the real
world) to break.

--
Chris Green
·

[Chris Green]

Scott Alfter <sc...@alfter.diespammersdie.us> wrote:
> In article <upc13i$16fsg$1...@dont-email.me>,
> Pancho <Pancho...@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.
>

Which is of course the default setup with ssh. You generate a key on
the client and that client key will get copied to all the systems to
which that client wants to connect.

I (like most ssh users I suspect) only have two ssh client machines,
my desktop and my laptop. They each have thirty or forty remote
systems they connect to. If either got stolen it would be quite a job
to remove all the remote keys!

--
Chris Green
·

[Chris Green]

Chris Green <c...@isbd.net> wrote:
> Scott Alfter <sc...@alfter.diespammersdie.us> wrote:
> > In article <upc13i$16fsg$1...@dont-email.me>,
> > Pancho <Pancho...@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.
> >
> Which is of course the default setup with ssh. You generate a key on
> the client and that client key will get copied to all the systems to
> which that client wants to connect.
>

The public key that is, of course.

> I (like most ssh users I suspect) only have two ssh client machines,
> my desktop and my laptop. They each have thirty or forty remote
> systems they connect to. If either got stolen it would be quite a job
> to remove all the remote keys!
>
> --
> Chris Green
> ·

--
Chris Green
·

[Ahem A Rivet's Shot]

On Tue, 30 Jan 2024 22:43:16 -0500
"68g.1499" <68g....@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.

[Ahem A Rivet's Shot]

On Wed, 31 Jan 2024 07:03:10 +0000
Chris Green <c...@isbd.net> wrote:

> Scott Alfter <sc...@alfter.diespammersdie.us> wrote:
> > In article <-FadnQKrpYU-sir4...@earthlink.com>,

> > For remote access (to a headless box or otherwise), you should be using
> > key-based authentication anyway and should disable password
> > authentication in sshd.
> >
> Why specifically?

The key phrase here is "for remote access".

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

Yep the key(s) for remote access should not be the keys for local
access. Ideally they only get you onto a gateway machine from which you
access the rest by passwords or keys as you choose.

Some time back I decided this was too much hassle and set up a VPN
for outside access, now all I have to worry about are the VPN keys.

[Theo]

Chris Green <c...@isbd.net> wrote:
> Scott Alfter <sc...@alfter.diespammersdie.us> wrote:
> > In article <-FadnQKrpYU-sir4...@earthlink.com>,
> > 68g.1499 <68g....@etr6.net> wrote:
> > > On install, you CAN select 'pi' as the username and anything
> > > you want as the password. It WILL complain - but will do it
> > > if you demand. If you change passwords later there's more of
> > > a chance it will demand "minimum complexity" (that's deep in
> > > the PAM stuff).
> >
> > For remote access (to a headless box or otherwise), you should be using
> > key-based authentication anyway and should disable password authentication
> > in sshd.
> >
> Why specifically?

Keys with a passphrase cover 'something you have' as well as 'something you
know', which is two of the three factors (the other being 'something you
are', ie biometrics).

Passwords are just 'something you know', ie once the password is stolen
anyone can reuse it. For example passwords can be keylogged or phished,
while keys can't be (the phishing site doesn't get your private key and
can't replaying the transaction).

Unlike the web, SSH uses host keys to reduce the risk of phishing but do you
check the host key the first time you connect? Plus keylogging is a real
concern - there are cracked SSH daemons which record the passwords and send
them to attackers.

> 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 that is a concern, don't unlock your keys until you need to use them.
Desktop environments often run an ssh-agent to hold your keys for you so you
only need type the passphrase once per login/time period, but you can
disable that behaviour. Plus you can use different keys for different
purposes - eg a work key and a home key, so you don't unlock your work key
unless you're doing work stuff.

> I *could* generate a separate key for every remote and force it to ask
> for the key every time I log in but that adds extra hassle every time
> I add or change a remote system.

Asking for the passphrase is no more complex than asking for a password,
surely?

> Using the default (ssh password authentication) means that I have no
> extra configuration required to either default or local system **and**
> no on can casually walk up to desktop or laptop and get a login to a
> remote.

Even if you change nothing on the server end, it's still good to use keys
where you can. If you never send the password there's nothing to keylog or
phish. You could even unset your password so password auth will never
succeed. But it's only a one line change in /etc/ssh/sshd_config to disable
password auth altogether.

Theo

[Richard Kettlewell]

Chris Green <c...@isbd.net> writes:

> Scott Alfter <sc...@alfter.diespammersdie.us> 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.
>
> Why specifically?
>
> 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.

There are things you can do about this (screen lock, full disk
encryption, etc) but your choices may depend on the nature of the
threat. e.g. a dishonest cleaner could be deterred by a screen lock, but
an abusive partner might respond with violence to any visible security
measures.

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

[Ahem A Rivet's Shot]

On Wed, 31 Jan 2024 11:29:44 +0000
Richard Kettlewell <inv...@invalid.invalid> wrote:

> There are things you can do about this (screen lock, full disk

Screen lock really should be a minimum consideration. Easy to do
and good enough for most purposes, fingerprint unlock is convenient if
available.

> encryption, etc) but your choices may depend on the nature of the
> threat. e.g. a dishonest cleaner could be deterred by a screen lock, but
> an abusive partner might respond with violence to any visible security
> measures.

Things are serious when the threat surface includes your skin!

[Theo]

Theo <theom...@chiark.greenend.org.uk> wrote:
> Even if you change nothing on the server end, it's still good to use keys
> where you can. If you never send the password there's nothing to keylog or
> phish. You could even unset your password so password auth will never
> succeed. But it's only a one line change in /etc/ssh/sshd_config to disable
> password auth altogether.

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

[Ahem A Rivet's Shot]

On 31 Jan 2024 13:40:11 +0000 (GMT)

Theo <theom...@chiark.greenend.org.uk> wrote:

> A one liner to disable password auth, works on Ubuntu and Raspberry Pi OS:

It will work on just about any unixish system with sshd.

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

[Chris Green]

Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> On Wed, 31 Jan 2024 07:03:10 +0000
> Chris Green <c...@isbd.net> wrote:
>
> > Scott Alfter <sc...@alfter.diespammersdie.us> wrote:
> > > In article <-FadnQKrpYU-sir4...@earthlink.com>,
>
> > > For remote access (to a headless box or otherwise), you should be using
> > > key-based authentication anyway and should disable password
> > > authentication in sshd.
> > >
> > Why specifically?
>
> The key phrase here is "for remote access".
>
> > 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,
>
> Yep the key(s) for remote access should not be the keys for local
> access. Ideally they only get you onto a gateway machine from which you
> access the rest by passwords or keys as you choose.
>

OK, since I'm more worried about people breaking **into** my home
desktop machine rather than the security of all the remotes 'out
there' that's exactly what I do, use a gateway for access. Well,
actually two gateways so that if one fails I can still use the other.
The home firewall is set up to all ssh connections only from two IP
addresses.

All the remote systems I connect to from my home machine (or my
laptop) are of little conesequence security wise. One for example is
a Beaglebone Black monitoring the battery voltages on my boat.

> Some time back I decided this was too much hassle and set up a VPN
> for outside access, now all I have to worry about are the VPN keys.
>

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.

--
Chris Green
·

[Chris Green]

Richard Kettlewell <inv...@invalid.invalid> wrote:
> Chris Green <c...@isbd.net> writes:
> > Scott Alfter <sc...@alfter.diespammersdie.us> 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.
> >
> > Why specifically?
> >
> > 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.

> There are things you can do about this (screen lock, full disk
> encryption, etc) but your choices may depend on the nature of the
> threat. e.g. a dishonest cleaner could be deterred by a screen lock, but
> an abusive partner might respond with violence to any visible security
> measures.
>

Quite.


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

--
Chris Green
·

[Chris Green]

Theo <theom...@chiark.greenend.org.uk> wrote:
> Chris Green <c...@isbd.net> wrote:
>

> > I *could* generate a separate key for every remote and force it to ask
> > for the key every time I log in but that adds extra hassle every time
> > I add or change a remote system.
>
> Asking for the passphrase is no more complex than asking for a password,
> surely?
>
> > Using the default (ssh password authentication) means that I have no
> > extra configuration required to either default or local system **and**
> > no on can casually walk up to desktop or laptop and get a login to a
> > remote.
>
> Even if you change nothing on the server end, it's still good to use keys
> where you can. If you never send the password there's nothing to keylog or
> phish. You could even unset your password so password auth will never
> succeed. But it's only a one line change in /etc/ssh/sshd_config to disable
> password auth altogether.
>

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.

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

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

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


--
Chris Green
·

[Theo]

Ahem A Rivet's Shot <ste...@eircom.net> wrote:

> On 31 Jan 2024 13:40:11 +0000 (GMT)
> Theo <theom...@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

[Theo]

Chris Green <c...@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 ch...@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

[Adam Funk]

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.

[Adam Funk]

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>

[Theo]

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

[The Natural Philosopher]

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

[The Natural Philosopher]

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.

[Theo]

The Natural Philosopher <t...@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

[Charlie Gibbs]

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:
\ / <cgi...@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.

[Charlie Gibbs]

On 2024-01-31, Chris Green <c...@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.

[Pancho]

On 30/01/2024 23:39, Scott Alfter wrote:
> In article <upc13i$16fsg$1...@dont-email.me>,
> Pancho <Pancho...@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.

[Richard Kettlewell]

Chris Green <c...@isbd.net> writes:
> Richard Kettlewell <inv...@invalid.invalid> wrote:
>> Chris Green <c...@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/

[druck]

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

[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

[68g.1499]

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

[68g.1499]

On 1/30/24 6:05 PM, Scott Alfter wrote:
> In article <k4fd8k-d...@esprimo.zbmc.eu>,
> Chris Green <c...@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.

[Chris Green]

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
·

[Pancho]

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.

[Pancho]

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.

[Richard Kettlewell]

Pancho <Pancho...@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/

[Richard Kettlewell]

"68g.1499" <68g....@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/

[Adam Funk]

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.

[The Natural Philosopher]

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

[Scott Alfter]

In article <zQKdnaXu1ZFtpyb4...@earthlink.com>,

68g.1499 <68g....@etr6.net> wrote:
>On 1/30/24 6:05 PM, Scott Alfter wrote:
>> In article <k4fd8k-d...@esprimo.zbmc.eu>,
>> Chris Green <c...@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?

[The Natural Philosopher]

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

[druck]

On 01/02/2024 08:12, Pancho wrote:
>> 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.

Not it you have a way of replicating the .ssh/authorized_keys file
between machines. You can do it with a cron script that does a copy
every few minutes if the master changes.

---druck

[Theo]

Chris Green <c...@isbd.net> wrote:
> Theo <theom...@chiark.greenend.org.uk> wrote:
> > Chris Green <c...@isbd.net> wrote:
> > 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 ch...@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.

I wasn't advocating that. The agent's purpose is so you only have to type
the passphrase once per session - if that makes keys easier to use and maybe
helps you have a stronger passphrase (since you don't need to type it so
often), then why not?

There may be some threat models where you don't want your machine holding
unlocked keys in RAM, in which case fair enough and you need to type the
passphrase each time, but for many use cases ssh-agent (and its integration
into things like KDE KWallet or MacOS keychain) is fine.

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

If the keylogger is running locally, stealing the passphrase from a key
won't help the attacker because they don't have the private key.

If the keylogger in an infected SSH daemon on the server (which is where SSH
passwords are typically harvested) it will see parts of the public key
exchange but it doesn't see your passphrase or private key and the protocol
is designed so you can't replay what it does see. If it has passwords it
can replay them on other sites.

> > etckeeper will keep track of changes to /etc in a git repo
> >
> I use Mercurial.

etckeeper supports that too.

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

I suppose you could push/pull your etckeeper repo to keep your /etc in sync,
but probably not ideal since things like hostnames will be different between
machines. Ansible is a better bet.

Theo

[68g.1499]

Um ... printers have come with network ports/wi-fi for at
least 15 or more years now. You don't need "long cables",
except for ethernet, and thus the printer can be 300+ meters
away in the junk shed and work just fine. You can see and
print to it from any PC-like-thing directly.

Now if you have one of those old OKI pin printers (they
still have their place and they still sell them) with RS-232
then you may need a cheap adapter (or two) but you can still
plug 'em into the ethernet or at least a modern box and
share 'em out.

So ... well, I promised not to ask :-)

The increasing difficulty with "headless" is more of an
issue these days IMHO. I rarely did totally headless, but
on a few lower-powered (Pi) units that was the better
way to go to save resources. Even 'simple' GUIs are
cpu/memory-hogs at the least.

For easy headless in the near future ... might want to
look at the BSDs ...... some pain, some gain ......

[The Natural Philosopher]

Some have, but many people use printers older than that.
Or more recent ones that come without network ports or wifi



--
Religion is regarded by the common people as true, by the wise as
foolish, and by the rulers as useful.

(Seneca the Younger, 65 AD)

[68g.1499]

Um ... check Amazon for adapters. You MIGHT need two.
However you OUGHT to be able to get it on ethernet or
wi-fi or at least USB on some box where you can share
it out. Fifty bucks ?

Now for 1970s/80s printers ... wide Centronics parallel ...
ok, you ARE gonna have problems, serious problems ....

RS-232 printers though, far fewer problems beyond drivers.
Kept an ancient OKI Microline going for 25 years ... THE
thing for multi-page sales forms. They still sell 'em.

Anyway, I promised not to ask ... :-)

[68g.1499]

Had an old HP pen plotter and HiPad plotting tablet
- RS-232. A Pi could work them directly, no 'server'
required. You MIGHT want a couple of adapters so you
can use USB ports, but the built-in serial works
just fine. DRIVERS for old serial printers, they
MIGHT still be found ... but the command sets were
pretty simple anyway .......

Also, you don't need to use a Pi intermediary, even
crappy Winders PCs can be convinced to use/share
such devices. Linux/Unix can be even better because
they still understand TTY devices better.

[Chris Green]

Theo <theom...@chiark.greenend.org.uk> wrote:
> Chris Green <c...@isbd.net> wrote:
> > Theo <theom...@chiark.greenend.org.uk> wrote:
> > > Chris Green <c...@isbd.net> wrote:
> > > 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 ch...@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.
>
> I wasn't advocating that. The agent's purpose is so you only have to type
> the passphrase once per session - if that makes keys easier to use and maybe
> helps you have a stronger passphrase (since you don't need to type it so
> often), then why not?
>

This is where we came in! :-)

If you use agent then, once the passphrase has been entered, anyone
can walk up and log in to that remote system without know the passphrase.

--
Chris Green
·

[Chris Elvidge]

On 02/02/2024 07:11, 68g.1499 wrote:

> Um ... printers have come with network ports/wi-fi for at
> least 15 or more years now.

SOME printers have ....

If a guy wants to run a Pi as a print server, who are you to say it's
wrong? They're very good for USB only printers.


--
Chris Elvidge, England
I WILL ONLY DO THIS ONCE A YEAR

[druck]

On 31/01/2024 03:43, 68g.1499 wrote:
>   "Popular" systems - Win/Android/Mac - are going to be the
>   primary targets, bots and such optimized for them. Linux
>   proper is there, but not super-popular by the percentages.
>   Win in particular is a security disaster and most users
>   are know-nothings, best to put efforts there.

No,these days they are looking to recruit POS Chinese IOT stuff running,
such as security cameras, "smart" kitchen app licences and god knows
what else.

What these things have in common is running a version of Linux with very
poor security, such as hardcoded passwords, insecure protocols, no
firewalls or intrusion detection, and no one logged in running tools to
see why they are slow or are sending data all over the internet (even
more than the telemetry than they are meant to send back to the mothership).

Don't make your Raspberry as easy to crack as these things!

---druck

[Anssi Saari]

sc...@alfter.diespammersdie.us (Scott Alfter) writes:

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

And this works for you? I tried to setup a Pi as a print server but it
was just bad. Printer was a Laserjet but not so old it could take PCL or
postscript. Something proprietary that has been thoroughly reverse
engineered long ago, don't remember exactly what right now.

For me this setup was extremely flaky over the network. Sure, I could
print a test page but actual print jobs were really hit or
miss. Typically Cups on the Pi would say the job printed fine but
nothing actually came out of the printer. Reprinting from the Cups
"completed jobs" list always worked though. Sometimes Cups just decided
the printer wasn't "reachable". Even when it worked it was super slow for
one or two page text only jobs, say something like minutes for a file of
a few dozen kB to a few hundred.

Eventually the Pi ate its SD card and I got a cheapo ink jet. Still,
that old Laserjet should have something like 2000 pages worth of toner
left in its cartridge so sometimes I think about trying again.

[Adam Funk]

On 2024-01-31, Charlie Gibbs wrote:

> On 2024-01-31, Adam Funk <a24...@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.

I remember laughing at that at too.


--
A man can't just sit around.
---Larry Walters

[Adam Funk]

On 2024-02-01, Theo wrote:

> Chris Green <c...@isbd.net> wrote:

>> Not true, you're advocating separate keys for each remote and not
>> keeping thenm in an agent so login isn't 'passwordless' or automatic.
>
> I wasn't advocating that. The agent's purpose is so you only have to type
> the passphrase once per session - if that makes keys easier to use and maybe
> helps you have a stronger passphrase (since you don't need to type it so
> often), then why not?
>
> There may be some threat models where you don't want your machine holding
> unlocked keys in RAM, in which case fair enough and you need to type the
> passphrase each time, but for many use cases ssh-agent (and its integration
> into things like KDE KWallet or MacOS keychain) is fine.

You can use `ssh-add -D` to delete all keys from the agent or `ssh-add
-t 1h` (for example) to limit the keys' life in the agent to 1 hour.


--
I only regret that I have but one shirt to give for my country.
---Abbie Hoffman

[Scott Alfter]

In article <ljidnQZAhaC5ACH4...@earthlink.com>,

68g.1499 <68g....@etr6.net> wrote:
> Also, you don't need to use a Pi intermediary, even
> crappy Winders PCs can be convinced to use/share
> such devices. Linux/Unix can be even better because
> they still understand TTY devices better.

You don't have to, but when your primary computer dual-boots, it makes
things easier. Besides, it was sitting idle, and even the first-gen
Raspberry Pi is more than capable enough for the task.

[Scott Alfter]

In article <sm0jznm...@lakka.kapsi.fi>,

Anssi Saari <anssi...@usenet.mail.kapsi.fi> wrote:
>sc...@alfter.diespammersdie.us (Scott Alfter) writes:
>
>> 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.
>
>And this works for you? I tried to setup a Pi as a print server but it
>was just bad. Printer was a Laserjet but not so old it could take PCL or
>postscript. Something proprietary that has been thoroughly reverse
>engineered long ago, don't remember exactly what right now.

I had it working at first by (ab)using netcat somewhat, but I eventually
tracked down some ancient print-serving code:

https://web.archive.org/web/20021127142540/http://www.lprng.com/DISTRIB/UNIXTOOLS/lp_server/lp_server-1.1.6.tgz

I had to tweak it a bit to build on modern systems (still have to compile it
with -std=c90, though), and I had to tweak it further to work without glibc
so it'd run on Alpine. The result is up here, along with instructions:

https://gitlab.alfter.us/salfter/lp_server

CUPS (running on Gentoo Linux on another host) has been pretty solid talking
to both of the printers I use with it. Win11 works well with it, too.

I think I'd tried setting up CUPS on the Raspberry Pi before, but ran into
problems. Setting it up as a JetDirect-workalike has worked out much
better.

[Scott Alfter]

In article <lQydnVSjD-c-CCH4...@earthlink.com>,

68g.1499 <68g....@etr6.net> wrote:
>On 2/1/24 9:40 AM, The Natural Philosopher wrote:
>> On 01/02/2024 06:32, 68g.1499 wrote:
>>>    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...
>
> Um ... printers have come with network ports/wi-fi for at
> least 15 or more years now. You don't need "long cables",
> except for ethernet, and thus the printer can be 300+ meters
> away in the junk shed and work just fine. You can see and
> print to it from any PC-like-thing directly.

The printers I'm connecting that way are definitely older than that. There
was a LaserJet 1320n that had built-in Ethernet connectivity, but that
wasn't what I'd bought the better part of 20 years ago.

[The Natural Philosopher]

The great thing about JetDirect was the utter lack of cleverness. Not
much could go wrong with it

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

[68g.1499]

On 2/2/24 11:16 AM, Scott Alfter wrote:
> In article <ljidnQZAhaC5ACH4...@earthlink.com>,
> 68g.1499 <68g....@etr6.net> wrote:
>> Also, you don't need to use a Pi intermediary, even
>> crappy Winders PCs can be convinced to use/share
>> such devices. Linux/Unix can be even better because
>> they still understand TTY devices better.
>
> You don't have to, but when your primary computer dual-boots, it makes
> things easier. Besides, it was sitting idle, and even the first-gen
> Raspberry Pi is more than capable enough for the task.

Fully agreed - a Pi-1 (and I have a few) is fully capable.
Just questioning the NEED.

But, if you want it that way ...

[68g.1499]

Which is why I also addressed "old"/RS-232 type
printers.

SERIAL - easy to deal with. Parallel/Centronics,
not so easy these days.

However NEW printers are NOT very expensive.
Let go of the distant past ...... :-)

[68g.1499]

On 2/2/24 8:01 AM, Chris Elvidge wrote:
> On 02/02/2024 07:11, 68g.1499 wrote:
>>    Um ... printers have come with network ports/wi-fi for at
>>    least 15 or more years now.
>
> SOME printers have ....

LOTS of printers ....

Yea, I fully understand the urge to "keep what works",
but eventually there's a POINT .......

> If a guy wants to run a Pi as a print server, who are you to say it's
> wrong? They're very good for USB only printers.

I didn't say it was bad/stupid.

I just said there may be better solutions.

If he badly WANTS to do it that way ...

So don't put words in my mouth.

[68g.1499]

On 2/2/24 11:34 AM, Scott Alfter wrote:
> In article <lQydnVSjD-c-CCH4...@earthlink.com>,
> 68g.1499 <68g....@etr6.net> wrote:
>> On 2/1/24 9:40 AM, The Natural Philosopher wrote:
>>> On 01/02/2024 06:32, 68g.1499 wrote:
>>>>    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...
>>
>> Um ... printers have come with network ports/wi-fi for at
>> least 15 or more years now. You don't need "long cables",
>> except for ethernet, and thus the printer can be 300+ meters
>> away in the junk shed and work just fine. You can see and
>> print to it from any PC-like-thing directly.
>
> The printers I'm connecting that way are definitely older than that. There
> was a LaserJet 1320n that had built-in Ethernet connectivity, but that
> wasn't what I'd bought the better part of 20 years ago.

The HPLJ-2 was a damned workin' MACHINE. Almost
indestructible. Good quality, acceptable speed.

But it wasn't Wi-Fi.

But it COULD be Wi-Fi or Ethernet. Just takes a
cheap adapter or two. You can also SHARE it from
a Win or Lin unit. No need for intermediary stuff.

Anyway, just saying that there ARE solutions beyond
a dedicated print server. Easier, more future
utility.

[Pancho]

On 01/02/2024 08:43, Richard Kettlewell wrote:

>
> 3) Use certificate-based authentication. Instead of copying public keys
> everywhere, just sign them once, and get each endpoint to trust the
> CA.
>
Thanks, I think the idea of certificate-based authentication sounds
interesting.

I will give it a go, I should at least understand what it means, even if
it is ultimately not appropriate.

[Pancho]

Yep replication seems a good idea, I'm a little scared of roll your own
security automation. It's a topic that is both boring and tricky, a bad
combination. I can't see anyting wrong with it, but that often isn't a
good guide.

For the moment I think I'll investigate Richard's certificate base
authority idea. Thanks.

[68g.1499]

On 1/31/24 12:09 PM, The Natural Philosopher 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


Neither does your commercial laptop. Someone PUTS Winders
on it.

For a Pi you PUT Linux (or a few other options) on it.

Now C-64s came "equipped" ... the "OS" was burned into
the factory ROMs.

[druck]

On 02/02/2024 14:47, druck wrote:
> On 31/01/2024 03:43, 68g.1499 wrote:
>>    "Popular" systems - Win/Android/Mac - are going to be the
>>    primary targets, bots and such optimized for them. Linux
>>    proper is there, but not super-popular by the percentages.
>>    Win in particular is a security disaster and most users
>>    are know-nothings, best to put efforts there.
>
> No,these days they are looking to recruit POS Chinese IOT stuff running,
> such as security cameras, "smart" kitchen app licences and god knows
> what else.

Not even your toothbrush is safe!

https://www.tomshardware.com/networking/three-million-malware-infected-smart-toothbrushes-used-in-swiss-ddos-attacks-botnet-causes-millions-of-euros-in-damages

---druck

[Theo]

That may not actually be true. One of the 'major brands' of smart
toothbrushes just does Bluetooth to the phone app, and the data sent is just
things like battery level and head pressure:
https://filestore.fortinet.com/fortiguard/research/toothbrush.pdf

Which is not to say that some other brand doesn't have an internet-enabled
chip in there, but battery life would be bad and these things tend to
operate from small batteries which are wirelessly-charged once a week or
less. Also, to have the world's largest botnet outed in an obscure Swiss
newspaper seems a bit suspect.

The presentation above has some valid points about dumb cloud apps and
smart-toothbrush-linked dental insurance ("the better you brush the less you
pay") but that's a different thing from a botnet.

Theo