More to the point it's now illegal to have default usernames and passwords
in the UK, so the RPi folks have to comply.
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.
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 <cl@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 <tnp@invalid.invalid> wrote:
On 29/01/2024 04:54, 68g.1499 wrote:I've never understood how this can work. If you type a wrong password
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?
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 <cl@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.
On 29/01/2024 12:19, Chris Green wrote:
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 29/01/2024 04:54, 68g.1499 wrote:I've never understood how this can work. If you type a wrong password
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?
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.
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!
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.
no pro/State-level stuff. Sorry to burst many egos, but really
is YOUR server WORTH five CPU-seconds by N.Korea ???
The continuing most-dangerous thing out there is not "hacking" but
"human factors" -
On Tue, 30 Jan 2024 01:03:40 -0500
"68g.1499" <68g.1499@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.
Theo <theom+news@chiark.greenend.org.uk> wrote:
Chris Green <cl@isbd.net> wrote:OK, so it may be slightly more possible than I was surmising. However
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.
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! :-)
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?
I can't us Pi Imager because it's very broken on Ubuntu:-
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).
In article <-FadnQKrpYU-sir4nZ2dnZfqnPGdnZ2d@earthlink.com>,
68g.1499 <68g.1499@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.
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?
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 myIts also like bicycles in that a thief wont spend time on a worthless
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.
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.
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 article <-FadnQKrpYU-sir4nZ2dnZfqnPGdnZ2d@earthlink.com>,
68g.1499 <68g.1499@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.
In article <upc13i$16fsg$1@dont-email.me>,
Pancho <Pancho.Jones@proton.me> wrote:
On 30/01/2024 23:16, Scott Alfter wrote:
For remote access (to a headless box or otherwise), you should be using
key-based authentication anyway and should disable password authentication >> in sshd.
What is the usuaL set up for a home LAN, one key to rule them all, or a
key for each machine?
One key for each host that needs to connect. That way, if one of your computers gets stolen or is lost, you can revoke its access.
Scott Alfter <scott@alfter.diespammersdie.us> wrote:
In article <upc13i$16fsg$1@dont-email.me>,
Pancho <Pancho.Jones@proton.me> wrote:
On 30/01/2024 23:16, Scott Alfter wrote:
For remote access (to a headless box or otherwise), you should be using >> key-based authentication anyway and should disable password authentication
in sshd.
What is the usuaL set up for a home LAN, one key to rule them all, or a >key for each machine?
One key for each host that needs to connect. That way, if one of your computers gets stolen or is lost, you can revoke its access.
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
·
I'll still say the greatest risk is not hackers, but
USERS. They fall for all the tricks and install evilware
themselves.
Scott Alfter <scott@alfter.diespammersdie.us> wrote:
In article <-FadnQKrpYU-sir4nZ2dnZfqnPGdnZ2d@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?
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,
Scott Alfter <scott@alfter.diespammersdie.us> wrote:
In article <-FadnQKrpYU-sir4nZ2dnZfqnPGdnZ2d@earthlink.com>,
68g.1499 <68g.1499@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.
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.
Scott Alfter <scott@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.
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
On Wed, 31 Jan 2024 07:03:10 +0000
Chris Green <cl@isbd.net> wrote:
Scott Alfter <scott@alfter.diespammersdie.us> wrote:
In article <-FadnQKrpYU-sir4nZ2dnZfqnPGdnZ2d@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.
Chris Green <cl@isbd.net> writes:
Scott Alfter <scott@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.
Chris Green <cl@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.
On 31 Jan 2024 13:40:11 +0000 (GMT)
Theo <theom+news@chiark.greenend.org.uk> wrote:
A one liner to disable password auth, works on Ubuntu and Raspberry Pi OS: echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/10-passwordauth.conf ; sudo service ssh reload
It will work on just about any unixish system with sshd.
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 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).
More to the point it's now illegal to have default usernames and passwords
in the UK, so the RPi folks have to comply.
I'll leave you to follow through the logic (ss4-7), but RPi OS gets used in
a number of consumer and industrial products.
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>
On 2024-01-30, The Natural Philosopher wrote:
On 30/01/2024 06:03, 68g.1499 wrote:
The continuing most-dangerous thing out there is not "hacking" but
"human factors" -
My chief engineer went to do a security audit and install a corporate
firewall, and then test it.
His security report included:
- "The widespread use of dial in modems connecting to users DDI ports to
enable them to operate their windows desktop computers from home
represents a far greater security risk than that offered by the internet
connection....
How long ago was that?
- "The list of root passwords pinned up behind the receptionist desk as
well as the directory of usernames and DDI extensions is also sub
optimal...
Brilliant.
On 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
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'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.
Richard Kettlewell <invalid@invalid.invalid> wrote:
Chris Green <cl@isbd.net> writes:
That requires a knowledgeable attacker, just connection to a remoteOne 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.
doesn't.
However this is all quite academic really. It's security the other
way about (**into** my home system) that really matters.
In article <upc13i$16fsg$1@dont-email.me>,
Pancho <Pancho.Jones@proton.me> wrote:
On 30/01/2024 23:16, Scott Alfter wrote:
For remote access (to a headless box or otherwise), you should be using
key-based authentication anyway and should disable password authentication >>> in sshd.
What is the usuaL set up for a home LAN, one key to rule them all, or a
key for each machine?
One key for each host that needs to connect. That way, if one of your computers gets stolen or is lost, you can revoke its access.
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?
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.
On Tue, 30 Jan 2024 22:43:16 -0500
"68g.1499" <68g.1499@etr6.net> wrote:
I'll still say the greatest risk is not hackers, but
USERS. They fall for all the tricks and install evilware
themselves.
This is standard wisdom in the security game. Simulated phishing attacks are common in the workplace now - fall for one and get sent on a course, report one and get congratulated. Pity about the giveaway header
they all carry.
In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
Chris Green <cl@isbd.net> wrote:
I can't us Pi Imager because it's very broken on Ubuntu:-
Sounds like something you should take up with the Ubuntu packagers. I maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo eselect repository enable salfter && sudo emaint sync -r salfter), and it works like a champ.
More recently, I've migrated my print server (an ancient RPi Model B) from Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless. The
Alpine install needed to be done on a spare Raspberry Pi, but once it was up and running with ssh access, I was able to do the rest of the setup over the network. Once I had it configured as I wanted it, I brought the MicroSD card over to another computer to image it and shipped the image home so I could blast it onto an SD card. It's a much lighter-weight system now...could put it on a 128MB SD card, if I had one that small. :) The server runs headless, with just two printers, a network cable, and a power supply plugged in.
Chris Green <cl@isbd.net> wrote:
I don't disagreee with what you're saying but there's a load of configuration to do it all if, as is often the case, I'm rebuilding a Raspberry Pi for example.
On your machine:
ssh-copy-id pi@raspberrypi
On the Pi:
echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/10-passwordauth.conf
; sudo service ssh reload
That's it. Two lines.
"If you never send the password there's nothing to keylog or
phish" Ay? If there's a keylogger on your system it doesn't care
whether you're typing a password or a key. If it's logging what's
sent over the wire then it's encrypted.
The keylogger is often in a compromised SSH daemon on the server, rather
than in your machine. You connect to the server, it sees your password as you type it, it records your password and tries to login to other machines using it.
With keys, you never send the private key or passphrase over the connection. You tell your SSH client which key to use (or it tries several). The SSH client asks you for the passphrase to unlock the key (which is happening locally). You tell teh server which key you're using and it checks your authorized_keys for that public key.
The site sends you a challenge based on the public key, you compose a response to your challenge using the private key, you send the response.
If the server can decrypt the response you are in possession of the private key and the server proceeds to generate keys for this session.
If the keylogger is on your machine, it can get the passphrase but it
doesn't get the private key unless it is specifically designed for attacking ssh and can read your private keys. eg you might see the following in the keylog:
ssh chris@server.bigcorp.com
abr@cad4bra
ls
and it's clear that abr@cad4bra is your password. If that was your passphrase it wouldn't help attack anyone.
You **have** to start with password authentication so it's inevitably
there when you start with your headless Pi. Everything more to move
to one key per remote system is extra hassle which I have to repeat
when I rebuild the Pi (which can be quite frequently, e.g. two or
three times in a week).
You don't have to start with password auth. rpi-imager will allow you to install a public key into the Pi so you can SSH directly using keys. It
will also remember your settings so every time you flash a Pi, it gets your keys automatically.
So generate key (OK, that's only once per physical system), copy the
key to the remote using ssh-copy-id. Then go to the remote and edit /etc/ssh/sshd_config, then reboot and check it all works. Not a load
of work but enough to be a bit of a pain, plus I like to record configuration changes (like the sshd_config one).
etckeeper will keep track of changes to /etc in a git repo
If you want to do this to a lot of machines, it's worth learning Ansible as it'll keep your fleet of machines in sync. Just write an ansible recipe
and it will ensure it is applied (and only once) across all your
machines.
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.
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.
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 whichVery bad practice. Generate a new key on each device with ssh-keygen
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.
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.
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 ???
On 31/01/2024 16:02, Adam Funk wrote:
On 2024-01-30, The Natural Philosopher wrote:1997 or something?
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?
On 1/30/24 6:05 PM, Scott Alfter wrote:
In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
Chris Green <cl@isbd.net> wrote:
I can't us Pi Imager because it's very broken on Ubuntu:-
Sounds like something you should take up with the Ubuntu packagers. I
maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo
eselect
repository enable salfter && sudo emaint sync -r salfter), and it
works like
a champ.
More recently, I've migrated my print server (an ancient RPi Model B)
from
Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless. The
Alpine install needed to be done on a spare Raspberry Pi, but once it
was up
and running with ssh access, I was able to do the rest of the setup
over the
network. Once I had it configured as I wanted it, I brought the
MicroSD card
over to another computer to image it and shipped the image home so I
could
blast it onto an SD card. It's a much lighter-weight system
now...could put
it on a 128MB SD card, if I had one that small. :) The server runs
headless,
with just two printers, a network cable, and a power supply plugged in.
Ok ... I'm not gonna ask why you'd want a completely separate
print server, based on an old Pi, rather than just printing
directly from/to whatever :-)
On 1/30/24 6:05 PM, Scott Alfter wrote:
In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
Chris Green <cl@isbd.net> wrote:
I can't us Pi Imager because it's very broken on Ubuntu:-
Sounds like something you should take up with the Ubuntu packagers. I
maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo eselect >> repository enable salfter && sudo emaint sync -r salfter), and it works like >> a champ.
More recently, I've migrated my print server (an ancient RPi Model B) from >> Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless. The
Alpine install needed to be done on a spare Raspberry Pi, but once it was up >> and running with ssh access, I was able to do the rest of the setup over the >> network. Once I had it configured as I wanted it, I brought the MicroSD card
over to another computer to image it and shipped the image home so I could >> blast it onto an SD card. It's a much lighter-weight system now...could put >> it on a 128MB SD card, if I had one that small. :) The server runs headless, >> with just two printers, a network cable, and a power supply plugged in.
Ok ... I'm not gonna ask why you'd want a completely separate
print server, based on an old Pi, rather than just printing
directly from/to whatever :-)
In article <zQKdnaXu1ZFtpyb4nZ2dnZfqn_udnZ2d@earthlink.com>,
68g.1499 <68g.1499@etr6.net> wrote:
On 1/30/24 6:05 PM, Scott Alfter wrote:
In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
Chris Green <cl@isbd.net> wrote:
I can't us Pi Imager because it's very broken on Ubuntu:-
Sounds like something you should take up with the Ubuntu packagers. I
maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo eselect >>> repository enable salfter && sudo emaint sync -r salfter), and it works like
a champ.
More recently, I've migrated my print server (an ancient RPi Model B) from >>> Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless. The
Alpine install needed to be done on a spare Raspberry Pi, but once it was up
and running with ssh access, I was able to do the rest of the setup over the
network. Once I had it configured as I wanted it, I brought the MicroSD card
over to another computer to image it and shipped the image home so I could >>> blast it onto an SD card. It's a much lighter-weight system now...could put
it on a 128MB SD card, if I had one that small. :) The server runs headless,
with just two printers, a network cable, and a power supply plugged in.
Ok ... I'm not gonna ask why you'd want a completely separate
print server, based on an old Pi, rather than just printing
directly from/to whatever :-)
The printers in question (an HP LaserJet 1320 and a Zebra LP2844) don't have built-in network connectivity. The print server is basically a JetDirect-compatible box that receives print data on one port for one
printer and on another port for the other. I have an actual, rather old HP JetDirect print server in a box somewhere. It's in a box because its
10-Mbps Ethernet on one end and USB 1.x on the other is a bit slow for complex print jobs. Fast Ethernet (100 Mbps) and USB 2.0 on the Raspberry
Pi is a step up.
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.
Theo <theom+news@chiark.greenend.org.uk> wrote:
Chris Green <cl@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 chris@server.bigcorp.com
abr@cad4bra
ls
and it's clear that abr@cad4bra is your password. If that was your passphrase it wouldn't help attack anyone.
Not true, you're advocating separate keys for each remote and not
keeping thenm in an agent so login isn't 'passwordless' or automatic.
Thus, when I login I see:-
chris@esprimo$ ssh backup
Enter passphrase for key '/home/chris/.ssh/backup_id_rsa':
chris@backup$
... the keylogger will see 'ssh backup' followed by the passphrase.
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.
On 2/1/24 9:40 AM, The Natural Philosopher wrote:
On 01/02/2024 06:32, 68g.1499 wrote:
On 1/30/24 6:05 PM, Scott Alfter wrote:It avoids massively long printer cables obviously, when you have a
In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
Chris Green <cl@isbd.net> wrote:
I can't us Pi Imager because it's very broken on Ubuntu:-
Sounds like something you should take up with the Ubuntu packagers. I >>>> maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo
eselect
repository enable salfter && sudo emaint sync -r salfter), and it
works like
a champ.
More recently, I've migrated my print server (an ancient RPi Model
B) from
Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless. The >>>> Alpine install needed to be done on a spare Raspberry Pi, but once
it was up
and running with ssh access, I was able to do the rest of the setup
over the
network. Once I had it configured as I wanted it, I brought the
MicroSD card
over to another computer to image it and shipped the image home so I
could
blast it onto an SD card. It's a much lighter-weight system
now...could put
it on a 128MB SD card, if I had one that small. :) The server runs
headless,
with just two printers, a network cable, and a power supply plugged in. >>>
Ok ... I'm not gonna ask why you'd want a completely separate
print server, based on an old Pi, rather than just printing
directly from/to whatever :-)
pre-existent network of some sort...
Um ... printers have come with network ports/wi-fi for at
least 15 or more years now.
In article <zQKdnaXu1ZFtpyb4nZ2dnZfqn_udnZ2d@earthlink.com>,
68g.1499 <68g.1499@etr6.net> wrote:
On 1/30/24 6:05 PM, Scott Alfter wrote:
In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
Chris Green <cl@isbd.net> wrote:
I can't us Pi Imager because it's very broken on Ubuntu:-
Sounds like something you should take up with the Ubuntu packagers. I
maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo eselect >>> repository enable salfter && sudo emaint sync -r salfter), and it works like
a champ.
More recently, I've migrated my print server (an ancient RPi Model B) from >>> Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless. The
Alpine install needed to be done on a spare Raspberry Pi, but once it was up
and running with ssh access, I was able to do the rest of the setup over the
network. Once I had it configured as I wanted it, I brought the MicroSD card
over to another computer to image it and shipped the image home so I could >>> blast it onto an SD card. It's a much lighter-weight system now...could put
it on a 128MB SD card, if I had one that small. :) The server runs headless,
with just two printers, a network cable, and a power supply plugged in.
Ok ... I'm not gonna ask why you'd want a completely separate
print server, based on an old Pi, rather than just printing
directly from/to whatever :-)
The printers in question (an HP LaserJet 1320 and a Zebra LP2844) don't have built-in network connectivity. The print server is basically a JetDirect-compatible box that receives print data on one port for one
printer and on another port for the other. I have an actual, rather old HP JetDirect print server in a box somewhere. It's in a box because its
10-Mbps Ethernet on one end and USB 1.x on the other is a bit slow for complex print jobs. Fast Ethernet (100 Mbps) and USB 2.0 on the Raspberry
Pi is a step up.
On 01/02/2024 06:32, 68g.1499 wrote:
On 1/30/24 6:05 PM, Scott Alfter wrote:It avoids massively long printer cables obviously, when you have a pre-existent network of some sort...
In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
Chris Green <cl@isbd.net> wrote:
I can't us Pi Imager because it's very broken on Ubuntu:-
Sounds like something you should take up with the Ubuntu packagers. I
maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo
eselect
repository enable salfter && sudo emaint sync -r salfter), and it
works like
a champ.
More recently, I've migrated my print server (an ancient RPi Model B)
from
Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless. The
Alpine install needed to be done on a spare Raspberry Pi, but once it
was up
and running with ssh access, I was able to do the rest of the setup
over the
network. Once I had it configured as I wanted it, I brought the
MicroSD card
over to another computer to image it and shipped the image home so I
could
blast it onto an SD card. It's a much lighter-weight system
now...could put
it on a 128MB SD card, if I had one that small. :) The server runs
headless,
with just two printers, a network cable, and a power supply plugged in.
Ok ... I'm not gonna ask why you'd want a completely separate
print server, based on an old Pi, rather than just printing
directly from/to whatever :-)
On 01/02/2024 16:29, Scott Alfter wrote:
In article <zQKdnaXu1ZFtpyb4nZ2dnZfqn_udnZ2d@earthlink.com>,
68g.1499 <68g.1499@etr6.net> wrote:
On 1/30/24 6:05 PM, Scott Alfter wrote:
In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
Chris Green <cl@isbd.net> wrote:
I can't us Pi Imager because it's very broken on Ubuntu:-
Sounds like something you should take up with the Ubuntu packagers. I >>>> maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo
eselect
repository enable salfter && sudo emaint sync -r salfter), and it
works like
a champ.
More recently, I've migrated my print server (an ancient RPi Model
B) from
Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless. The >>>> Alpine install needed to be done on a spare Raspberry Pi, but once
it was up
and running with ssh access, I was able to do the rest of the setup
over the
network. Once I had it configured as I wanted it, I brought the
MicroSD card
over to another computer to image it and shipped the image home so I
could
blast it onto an SD card. It's a much lighter-weight system
now...could put
it on a 128MB SD card, if I had one that small. :) The server runs
headless,
with just two printers, a network cable, and a power supply plugged in. >>>
Ok ... I'm not gonna ask why you'd want a completely separate
print server, based on an old Pi, rather than just printing
directly from/to whatever :-)
The printers in question (an HP LaserJet 1320 and a Zebra LP2844)
don't have
built-in network connectivity. The print server is basically a
JetDirect-compatible box that receives print data on one port for one
printer and on another port for the other. I have an actual, rather
old HP
JetDirect print server in a box somewhere. It's in a box because its
10-Mbps Ethernet on one end and USB 1.x on the other is a bit slow for
complex print jobs. Fast Ethernet (100 Mbps) and USB 2.0 on the
Raspberry
Pi is a step up.
Yeah I had one of those for a big A1 plotter.
Pi is a great idea for a print server.
Chris Green <cl@isbd.net> wrote:
Theo <theom+news@chiark.greenend.org.uk> wrote:
Chris Green <cl@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 chris@server.bigcorp.com
abr@cad4bra
ls
and it's clear that abr@cad4bra is your password. If that was your passphrase it wouldn't help attack anyone.
Not true, you're advocating separate keys for each remote and not
keeping thenm in an agent so login isn't 'passwordless' or automatic.
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?
Um ... printers have come with network ports/wi-fi for at
least 15 or more years now.
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.
On 2024-01-31, Adam Funk <a24061@ducksburg.com> wrote:
On 2024-01-30, The Natural Philosopher wrote:
- "The list of root passwords pinned up behind the receptionist desk
as well as the directory of usernames and DDI extensions is also sub
optimal...
Brilliant.
I laughed when the movie WarGames showed the protagonist sitting
outside the principal's office, sliding out the writing leaf on the
desk on which a terminal sat, to reveal a piece of paper with the
password written on it. It was the most realistic part of the movie.
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 <cl@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.
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.
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 separateIt avoids massively long printer cables obviously, when you have a
print server, based on an old Pi, rather than just printing
directly from/to whatever :-)
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.
In article <sm0jznmlx0d.fsf@lakka.kapsi.fi>,
Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:
scott@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.
In article <ljidnQZAhaC5ACH4nZ2dnZfqnPWdnZ2d@earthlink.com>,
68g.1499 <68g.1499@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.
On 02/02/2024 07:11, 68g.1499 wrote:
On 2/1/24 9:40 AM, The Natural Philosopher wrote:
On 01/02/2024 06:32, 68g.1499 wrote:
On 1/30/24 6:05 PM, Scott Alfter wrote:It avoids massively long printer cables obviously, when you have a
In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
Chris Green <cl@isbd.net> wrote:
I can't us Pi Imager because it's very broken on Ubuntu:-
Sounds like something you should take up with the Ubuntu packagers. I >>>>> maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo
eselect
repository enable salfter && sudo emaint sync -r salfter), and it
works like
a champ.
More recently, I've migrated my print server (an ancient RPi Model
B) from
Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless. The >>>>> Alpine install needed to be done on a spare Raspberry Pi, but once
it was up
and running with ssh access, I was able to do the rest of the setup
over the
network. Once I had it configured as I wanted it, I brought the
MicroSD card
over to another computer to image it and shipped the image home so
I could
blast it onto an SD card. It's a much lighter-weight system
now...could put
it on a 128MB SD card, if I had one that small. :) The server runs
headless,
with just two printers, a network cable, and a power supply plugged
in.
Ok ... I'm not gonna ask why you'd want a completely separate
print server, based on an old Pi, rather than just printing
directly from/to whatever :-)
pre-existent network of some sort...
Um ... printers have come with network ports/wi-fi for at
least 15 or more years now.
Some have, but many people use printers older than that.
Or more recent ones that come without network ports or wifi
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.
In article <lQydnVSjD-c-CCH4nZ2dnZfqnPednZ2d@earthlink.com>,
68g.1499 <68g.1499@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 separateIt avoids massively long printer cables obviously, when you have a
print server, based on an old Pi, rather than just printing
directly from/to whatever :-)
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.
3) Use certificate-based authentication. Instead of copying public keys
everywhere, just sign them once, and get each endpoint to trust the
CA.
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.
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
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
| Sysop: | Xerxes |
|---|---|
| Location: | Azle, Texas |
| Users: | 119 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 134:36:00 |
| Calls: | 3,027 |
| Calls today: | 3 |
| Files: | 156 |
| U/L today: |
0 files (0K bytes) |
| D/L today: |
0 files (0K bytes) |
| Messages: | 294,113 |
| Posted today: | 0 |