• It is now very nearly impossible to install a headless Pi

    From Chris Green@3:770/3 to All on Fri Jan 26 19:52:20 2024
    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
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to Chris Green on Sat Jan 27 07:20:00 2024
    Chris Green <cl@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 |

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Bryan@3:770/3 to Computer Nerd Kev on Fri Jan 26 17:14:18 2024
    On 1/26/2024 16:20, Computer Nerd Kev wrote:
    Chris Green <cl@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.


    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Chris Green on Fri Jan 26 22:14:59 2024
    Chris Green <cl@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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim Jackson@3:770/3 to All on Fri Jan 26 22:28:11 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Lawrence D'Oliveiro@3:770/3 to Chris Green on Fri Jan 26 23:59:56 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Jim Jackson on Sat Jan 27 07:30:52 2024
    Jim Jackson <jj@franjam.org.uk> wrote:
    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

    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
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Theo on Sat Jan 27 07:34:51 2024
    Theo <theom+news@chiark.greenend.org.uk> wrote:
    Chris Green <cl@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
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Computer Nerd Kev on Sat Jan 27 07:27:50 2024
    Computer Nerd Kev <not@telling.you.invalid> wrote:
    Chris Green <cl@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
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From TimS@3:770/3 to All on Sat Jan 27 11:58:33 2024
    On 26 Jan 2024 at 22:14:59 GMT, "Theo" <theom+news@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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Chris Green on Sat Jan 27 11:22:15 2024
    Chris Green <cl@isbd.net> wrote:
    Theo <theom+news@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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to Chris Green on Sat Jan 27 15:07:50 2024
    On Sat, 27 Jan 2024 07:34:51 +0000
    Chris Green <cl@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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Lawrence D'Oliveiro@3:770/3 to TimS on Sat Jan 27 21:32:33 2024
    On 27 Jan 2024 11:58:33 GMT, TimS wrote:

    On 26 Jan 2024 at 22:14:59 GMT, "Theo"
    <theom+news@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?

    DEC/VMS joke. I think. ;)

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Richard Falken@1:135/115 to Chris Green on Sun Jan 28 06:26:38 2024
    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
    --- SBBSecho 3.20-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)
  • From 68g.1499@3:770/3 to Theo on Sun Jan 28 23:54:59 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Mon Jan 29 10:00:21 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to The Natural Philosopher on Mon Jan 29 12:19:21 2024
    The Natural Philosopher <tnp@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
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Chris Green on Mon Jan 29 13:33:38 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Theo on Mon Jan 29 13:42:16 2024
    On 29/01/2024 13:33, Theo wrote:
    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Chris Green on Mon Jan 29 13:36:37 2024
    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:
    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Theo on Mon Jan 29 19:26:13 2024
    Theo <theom+news@chiark.greenend.org.uk> wrote:
    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.

    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
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to The Natural Philosopher on Mon Jan 29 19:27:12 2024
    The Natural Philosopher <tnp@invalid.invalid> wrote:
    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:
    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.

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

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

    --
    Chris Green
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Lawrence D'Oliveiro@3:770/3 to Chris Green on Tue Jan 30 00:59:35 2024
    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 ...

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 68g.1499@3:770/3 to The Natural Philosopher on Tue Jan 30 01:03:40 2024
    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 ...

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to All on Tue Jan 30 10:23:53 2024
    T24gMjkvMDEvMjAyNCAxMDowMCwgVGhlIE5hdHVyYWwgUGhpbG9zb3BoZXIgd3JvdGU6DQo+ IE9uIDI5LzAxLzIwMjQgMDQ6NTQsIDY4Zy4xNDk5IHdyb3RlOg0KPj4gTm9ydGggS29yZWEg aXMgbm90DQo+PiDCoMKgIGdvaW5nIHRvIHNwZW5kIGZpdmUgZGF5cyB3b3J0aCBvZiBDUFUg dGltZSB0byBjcmFjayB5b3VyDQo+PiDCoMKgIGxpdHRsZSBob21lIFBpIGFuZCBpdHMgdmFs dWFibGUgaG9yZGUgb2YgIlJpY2sgYW5kIE1vcnR5Ig0KPj4gwqDCoCB2aWRzLiBZb3VyIGhv bWUgY29ubmVjdGlvbiBpcyBsaWtlbHkgdG9vIHNsb3cgdG8gYmUgdmVyeQ0KPj4gwqDCoCB1 c2VmdWwgZm9yIGxhdW5jaGluZyBicm9hZHNjYWxlIGF0dGFja3Mgb24gb3RoZXIgc3lzdGVt cw0KPj4gwqDCoCBhcyB3ZWxsLg0KDQpZb3VyIGJyb2FkYmFuZCBpcyBwbGVudHkgZmFzdCBl bm91Z2ggdG8gbGF1bmNoIERETlMgYXR0YWNrcyBhbG9uZyB3aXRoIA0KdGhvdXNhbmRzIG9m IG90aGVyIGNvbXByb21pc2VkIHN5c3RlbXMuIEl0J3MgdGhlIHNoZWVyIG51bWJlciBvZiAN CmNvbXByb21pc2VkIG1hY2hpbmVzIG9uIGEgYm90bmV0IHJhdGhlciB0aGFuIHRoZWlyIGNv bm5lY3Rpb24gc3BlZWRzIA0Kd2hpY2ggbWFrZXMgaXQgYSBwcm9ibGVtLg0KDQo+IEluZGVl ZC4gSSd2ZSB0d28gc2VydmVycyBvbiB0aGUgb3BlbiBpbnRlcm5ldCB3aXRoIG9wZW4gc3No IHBvcnRzIC4gSW4gOCANCj4geWVhcnMgYWx0aG91Z2ggdGhlcmUgaXMgYSBjb25zdGFudCBz dHJlYW0gb2YgbG9naW4gYXR0ZW1wdHMgbm8gb25lIGhhcyANCj4gZ3Vlc3NlZCB0aGUgY29y cmVjdCB1c2VyIG5hbWXCoCAtIGxldCBhbG9uZSB0aGUgcGFzc3dvcmQuDQoNCk1vc3Qgb2Yg dGhlIGF0dGVtcHRzIGFyZSBhZ2FpbnN0IHJvb3Qgb3Iga25vd24gc2VydmljZSBuYW1lcywg YnV0IHRoZXJlIA0KYXJlIGxvdHMgb2YgdXNlcm5hbWUvcGFzc3dvcmQgYXR0ZW1wdHMgd2hp Y2ggaGF2ZSBwcm9iYWJseSBjb21lIGZyb20gDQpvdGhlciBzdWNjZXNzZnVsbHkgY29tcHJv bWlzZWQgc3lzdGVtcywgcmVtaW5kaW5nIHlvdSB0byBuZXZlciByZXVzZSANCmNyZWRlbnRp YWxzLg0KDQo+IFBlb3BsZSBnZXQgcGFyYW5vaWQgYWJvdXQgc3R1ZmYgdGhleSB0aGluayB0 aGV5IGtub3cgYWJvdXQgYW5kIGZvcmdldCANCj4gdGhlIHNpbXBsZSB0aGluZ3MuDQo+IEHC oCBsb25nIGJ1dCBlYXNpbHkgbWVtb3JhYmxlIHN0cmluZyBsaWtlwqAgbXkuY2F0LmhhdGVz LlBJWlpBISB3aWxsIA0KPiBwcm9iYWJseSBmYWxsIHRvIGEgZGljdGlvbmFyeSBhdHRhY2sg aW4gYSBmZXcgdGhvdXNhbmQgaG91cnMsIGJ1dCANCj4gcmVhbGx5LCB3aG8gY2FyZXM/DQo+ IA0KPiBTb3JyeSwgeW91IGFyZSBub3QgdGhhdCBpbXBvcnRhbnQsIGFuZCBuZWl0aGVyIGFt IEkuDQoNCllvdXIgUGkgbWF5IG5vdCBiZSB2ZXJ5IGltcG9ydGFudCwgYnV0IGVsc2UgY2Fu IHRoZXkgZ2V0IHRvIG9uY2UgaW5zaWRlIA0KeW91ciBuZXR3b3JrPyBBbmQgZG8geW91IHJl YWxseSB3YW50IGl0IHRvIGJlIHVzZWQgdG8gYXR0YWNrIG90aGVycz8NCg0KLS0tZHJ1Y2sN Cg0KDQo=

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to 68g.1499@etr6.net on Tue Jan 30 10:08:34 2024
    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Tue Jan 30 11:37:36 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Tue Jan 30 11:45:30 2024
    On 30/01/2024 10:08, Ahem A Rivet's Shot wrote:
    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.

    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Chris Green on Tue Jan 30 11:38:27 2024
    On 29/01/2024 19:26, Chris Green wrote:
    Theo <theom+news@chiark.greenend.org.uk> wrote:
    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.

    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! :-)

    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"

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to druck on Tue Jan 30 11:49:22 2024
    On 30/01/2024 10:23, druck wrote:
    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?

    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to All on Tue Jan 30 21:11:51 2024
    T24gMzAvMDEvMjAyNCAxMTo0NSwgVGhlIE5hdHVyYWwgUGhpbG9zb3BoZXIgd3JvdGU6DQo+ IE9uIDMwLzAxLzIwMjQgMTA6MDgsIEFoZW0gQSBSaXZldCdzIFNob3Qgd3JvdGU6DQo+PiDC oMKgwqDCoEhvdyBtdWNoIGlzIGEgYm90bmV0IG5vZGUgd29ydGggPyBJbiBDUFUtc2Vjb25k cyA/IE9yIHRvIGludmVydCBpdA0KPj4gaG93IGNoZWFwbHkgY2FuIHRoZXkgYmUgb2J0YWlu ZWQgaW4gQ1BVLXNlY29uZHMuIEkgcHJlZmVyIHRoYXQgbXkgc3lzdGVtcw0KPj4gYXJlbid0 IGF0IHRoZSBsb3cgZW5kIG9mIHRoZSBsaXN0IGJ1dCByYXRoZXIgZmFyIGVub3VnaCB1cCBp dCB0aGF0IHRoZSANCj4+IGJ1bGsgaGFydmVzdGVycyB3b24ndCBib3RoZXIgbWUuDQo+Pg0K Pj4gwqDCoMKgwqBJdCdzIGxpa2UgYmljeWNsZSBsb2Nrcywgbm90aGluZyB3aWxsIHN0b3Ag YSBkZXRlcm1pbmVkIHRoaWVmIGJ1dA0KPj4gYW55IHRoaWVmIHdpbGwgZ28gZm9yIHRoZSBl YXN5IG9uZXMgZmlyc3Qgc28gZml0IHNvbWV0aGluZyBoYWxmIGRlY2VudCANCj4+IGJ1dCBk b24ndCBnbyBvdmVyIHRoZSB0b3AuDQo+Pg0KPiBJdHMgYWxzbyBsaWtlIGJpY3ljbGVzIGlu IHRoYXQgYSB0aGllZiB3b250IHNwZW5kIHRpbWUgb24gYSB3b3J0aGxlc3MgDQo+IGtpZHMg dHJpY3ljbGUuIFdoZW4gdGhlcmUgaXMgYSBjYXJib24gZmlicmUgbW91bnRhaW4gYmlrZSBw YXJrZWQgbmV4dCB0byANCj4gaXQuDQoNCkl0J3Mgbm90aGluZyBsaWtlIGJpY3ljbGVzLCBi b3RuZXQgaHVyZGVycyBkb24ndCBjYXJlIHdoYXQgdGhleSBhcmUgDQpjcmFja2luZywgYWRk aW5nIGFub3RoZXIgbm9kZSB0byBhIGJvdG5ldCBpcyB0aGUgZ29hbCBhbmQgb25lIGlzIHBy ZXR0eSANCm11Y2ggYXMgZ29vZCBhcyBhbm90aGVyLiBBbHNvIHRoZXkgYXJlbid0IHB1dHRp bmcgdGhlaXIgb3duIGVmZm9ydCBvciANCnRoZWlyIG93biBDUFUgY3ljbGVzIGludG8gY3Jh Y2tpbmcgbmV3IG1hY2hpbmVzLCBpdCdzIGJlaW5nIGRvbmUgYnkgYSANCnNjcmlwdCBydW5u aW5nIG9uIG90aGVyIHBlb3BsZXMgbWFjaGluZXMgYWxyZWFkeSBpbiB0aGUgYm90bmV0Lg0K DQotLS1kcnVjaw0KDQoNCg==

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Scott Alfter@3:770/3 to cl@isbd.net on Tue Jan 30 23:05:04 2024
    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Scott Alfter@3:770/3 to 68g.1499@etr6.net on Tue Jan 30 23:16:26 2024
    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to Scott Alfter on Tue Jan 30 23:35:15 2024
    On 30/01/2024 23:16, Scott Alfter 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.


    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?

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Scott Alfter@3:770/3 to Pancho.Jones@proton.me on Tue Jan 30 23:39:05 2024
    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 68g.1499@3:770/3 to druck on Tue Jan 30 22:43:16 2024
    On 1/30/24 4:11 PM, druck wrote:
    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 68g.1499@3:770/3 to The Natural Philosopher on Tue Jan 30 23:47:06 2024
    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 ..........

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Scott Alfter on Wed Jan 31 07:03:10 2024
    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.

    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
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Scott Alfter on Wed Jan 31 07:12:09 2024
    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
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Chris Green on Wed Jan 31 07:21:05 2024
    Chris Green <cl@isbd.net> wrote:
    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.

    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
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to 68g.1499@etr6.net on Wed Jan 31 07:47:23 2024
    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to Chris Green on Wed Jan 31 08:26:30 2024
    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Chris Green on Wed Jan 31 10:24:36 2024
    Chris Green <cl@isbd.net> wrote:
    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?

    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to Richard Kettlewell on Wed Jan 31 11:38:26 2024
    On Wed, 31 Jan 2024 11:29:44 +0000
    Richard Kettlewell <invalid@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!

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Richard Kettlewell@3:770/3 to Chris Green on Wed Jan 31 11:29:44 2024
    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Theo on Wed Jan 31 13:40:11 2024
    Theo <theom+news@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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to Theo on Wed Jan 31 14:09:42 2024
    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:

    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

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Ahem A Rivet's Shot on Wed Jan 31 14:29:11 2024
    Ahem A Rivet's Shot <steveo@eircom.net> wrote:
    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.

    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
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Richard Kettlewell on Wed Jan 31 14:40:26 2024
    Richard Kettlewell <invalid@invalid.invalid> wrote:
    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.

    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
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Theo on Wed Jan 31 14:38:14 2024
    Theo <theom+news@chiark.greenend.org.uk> wrote:
    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.

    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
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Ahem A Rivet's Shot on Wed Jan 31 15:35:32 2024
    Ahem A Rivet's Shot <steveo@eircom.net> wrote:
    On 31 Jan 2024 13:40:11 +0000 (GMT)
    Theo <theom+news@chiark.greenend.org.uk> wrote:

    A one liner to disable password auth, works on Ubuntu and Raspberry Pi OS: echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/10-passwordauth.conf ; sudo service ssh reload

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

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

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

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

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Adam Funk@3:770/3 to The Natural Philosopher on Wed Jan 31 16:02:53 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Chris Green on Wed Jan 31 16:03:38 2024
    Chris Green <cl@isbd.net> wrote:
    I don't disagreee with what you're saying but there's a load of
    configuration to do it all if, as is often the case, I'm rebuilding a Raspberry Pi for example.

    On your machine:

    ssh-copy-id pi@raspberrypi

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

    That's it. Two lines.

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

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

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

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

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

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

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

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

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

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

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

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

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Adam Funk@3:770/3 to Theo on Wed Jan 31 16:01:15 2024
    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>

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Theo on Wed Jan 31 17:09:44 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Adam Funk on Wed Jan 31 16:55:25 2024
    Adam Funk <a24061@ducksburg.com> wrote:
    On 2024-01-26, Theo wrote:

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

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

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

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

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

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

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

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

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Adam Funk on Wed Jan 31 16:55:57 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to The Natural Philosopher on Wed Jan 31 17:53:52 2024
    The Natural Philosopher <tnp@invalid.invalid> wrote:
    On 31/01/2024 16:55, Theo wrote:
    I'll leave you to follow through the logic (ss4-7), but RPi OS gets used in a number of consumer and industrial products.

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

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

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

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Charlie Gibbs@3:770/3 to Adam Funk on Wed Jan 31 19:33:28 2024
    On 2024-01-31, Adam Funk <a24061@ducksburg.com> wrote:

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

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

    Brilliant.

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

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Charlie Gibbs@3:770/3 to Chris Green on Wed Jan 31 19:33:30 2024
    On 2024-01-31, Chris Green <cl@isbd.net> wrote:

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Richard Kettlewell@3:770/3 to Chris Green on Wed Jan 31 21:09:26 2024
    Chris Green <cl@isbd.net> writes:
    Richard Kettlewell <invalid@invalid.invalid> wrote:
    Chris Green <cl@isbd.net> writes:

    One argument against using key based authentication (in my case
    anyway) is that my home desktop and my laptop (which are the ssh
    clients) are turned on and logged-into just about all the time. Thus,
    with the default log-in key used for authentication, all my remote
    systems would be accessible to someone just walking up to desktop or
    laptop.

    If an attacker can just walk up to your computer and run commands on it
    then they will install a keylogger and they will have any passwords you
    use next time you type them.

    That requires a knowledgeable attacker, just connection to a remote
    doesn't.

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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to Scott Alfter on Wed Jan 31 20:26:44 2024
    On 30/01/2024 23:39, Scott Alfter wrote:
    In article <upc13i$16fsg$1@dont-email.me>,
    Pancho <Pancho.Jones@proton.me> wrote:
    On 30/01/2024 23:16, Scott Alfter wrote:
    For remote access (to a headless box or otherwise), you should be using
    key-based authentication anyway and should disable password authentication >>> in sshd.

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

    One key for each host that needs to connect. That way, if one of your computers gets stolen or is lost, you can revoke its access.


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

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to Pancho on Wed Jan 31 21:18:32 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to Pancho on Wed Jan 31 21:25:44 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 68g.1499@3:770/3 to Ahem A Rivet's Shot on Thu Feb 1 01:18:00 2024
    On 1/31/24 2:47 AM, Ahem A Rivet's Shot wrote:
    On Tue, 30 Jan 2024 22:43:16 -0500
    "68g.1499" <68g.1499@etr6.net> wrote:

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

    This is standard wisdom in the security game. Simulated phishing attacks are common in the workplace now - fall for one and get sent on a course, report one and get congratulated. Pity about the giveaway header
    they all carry.


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

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

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

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

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

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

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

    Oh, found this today :

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

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

    It's a problem.

    It's getting worse, fast.

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 68g.1499@3:770/3 to Scott Alfter on Thu Feb 1 01:32:15 2024
    On 1/30/24 6:05 PM, Scott Alfter wrote:
    In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
    Chris Green <cl@isbd.net> wrote:
    I can't us Pi Imager because it's very broken on Ubuntu:-

    Sounds like something you should take up with the Ubuntu packagers. I maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo eselect repository enable salfter && sudo emaint sync -r salfter), and it works like a champ.

    More recently, I've migrated my print server (an ancient RPi Model B) from Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless. The
    Alpine install needed to be done on a spare Raspberry Pi, but once it was up and running with ssh access, I was able to do the rest of the setup over the network. Once I had it configured as I wanted it, I brought the MicroSD card over to another computer to image it and shipped the image home so I could blast it onto an SD card. It's a much lighter-weight system now...could put it on a 128MB SD card, if I had one that small. :) The server runs headless, with just two printers, a network cable, and a power supply plugged in.


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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Theo on Thu Feb 1 07:41:19 2024
    Theo <theom+news@chiark.greenend.org.uk> wrote:
    Chris Green <cl@isbd.net> wrote:
    I don't disagreee with what you're saying but there's a load of configuration to do it all if, as is often the case, I'm rebuilding a Raspberry Pi for example.

    On your machine:

    ssh-copy-id pi@raspberrypi

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

    That's it. Two lines.

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

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

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

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

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

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

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

    Not true, you're advocating separate keys for each remote and not
    keeping thenm in an agent so login isn't 'passwordless' or automatic.

    Thus, when I login I see:-

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

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




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

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

    Yes, I'd forgotten that I must admit, I may start doing it in fact as
    using rpi-imager is becoming more necessary anyway.


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

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

    I use Mercurial.

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

    I may take a look, though I already have a common Mercurial repository
    where I keep everything like .bashrc, .profile, .ssh/config and so on.
    The Mercurial repository is shared across systems using syncthing.

    --
    Chris Green
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to druck on Thu Feb 1 08:12:32 2024
    On 31/01/2024 21:25, druck wrote:
    On 31/01/2024 20:26, Pancho wrote:
    Yes, I understand the need for unique keys for clients which operate
    outside the home, like a laptop, but what about for the LAN only
    devices? For instance, a rPi using scp to another rPi. I have quite a
    few Pis.

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

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


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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to druck on Thu Feb 1 08:17:00 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Richard Kettlewell@3:770/3 to Pancho on Thu Feb 1 08:43:51 2024
    Pancho <Pancho.Jones@proton.me> writes:
    On 31/01/2024 21:25, druck wrote:
    On 31/01/2024 20:26, Pancho wrote:
    Yes, I understand the need for unique keys for clients which
    operate outside the home, like a laptop, but what about for the LAN
    only devices? For instance, a rPi using scp to another rPi. I have
    quite a few Pis.

    When I set up a new machine, it is often easier to use an existing
    key which already has been installed on all SSH servers, so I use a
    single one. Often, I just copy the ~/.ssh folder. I suppose I could
    reuse a currently unused key from a pool of configured keys, but it
    seems like a lot of work.
    Very bad practice. Generate a new key on each device with ssh-keygen
    and copy it to your primary machine with ssh-copy-id Then replicate
    the primary machines .ssh/authorized_keys file to all the others, so
    you can login from any machine to any other.

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

    You’ve got several reasonable options:

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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Richard Kettlewell@3:770/3 to 68g.1499@etr6.net on Thu Feb 1 08:48:57 2024
    "68g.1499" <68g.1499@etr6.net> writes:
    Similar experiences here too and more like 15 years. They always
    seem to use a list of "common usernames" and another list of
    "common passwords". The 'smartest' one used some names from
    the company e-mail acct. In short, all script kiddies - bots -
    no pro/State-level stuff. Sorry to burst many egos, but really
    is YOUR server WORTH five CPU-seconds by N.Korea ???

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

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

    - Fleets of hacked computers are used in DDoS attacks.

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

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Adam Funk@3:770/3 to The Natural Philosopher on Thu Feb 1 11:10:00 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Thu Feb 1 14:40:31 2024
    On 01/02/2024 06:32, 68g.1499 wrote:
    On 1/30/24 6:05 PM, Scott Alfter wrote:
    In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
    Chris Green  <cl@isbd.net> wrote:
    I can't us Pi Imager because it's very broken on Ubuntu:-

    Sounds like something you should take up with the Ubuntu packagers.  I
    maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo
    eselect
    repository enable salfter && sudo emaint sync -r salfter), and it
    works like
    a champ.

    More recently, I've migrated my print server (an ancient RPi Model B)
    from
    Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless.  The
    Alpine install needed to be done on a spare Raspberry Pi, but once it
    was up
    and running with ssh access, I was able to do the rest of the setup
    over the
    network.  Once I had it configured as I wanted it, I brought the
    MicroSD card
    over to another computer to image it and shipped the image home so I
    could
    blast it onto an SD card.  It's a much lighter-weight system
    now...could put
    it on a 128MB SD card, if I had one that small. :) The server runs
    headless,
    with just two printers, a network cable, and a power supply plugged in.


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

    It avoids massively long printer cables obviously, when you have a
    pre-existent network of some sort...


    r worse) code.


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

    —Soren Kierkegaard

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Scott Alfter@3:770/3 to 68g.1499@etr6.net on Thu Feb 1 16:29:53 2024
    In article <zQKdnaXu1ZFtpyb4nZ2dnZfqn_udnZ2d@earthlink.com>,
    68g.1499 <68g.1499@etr6.net> wrote:
    On 1/30/24 6:05 PM, Scott Alfter wrote:
    In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
    Chris Green <cl@isbd.net> wrote:
    I can't us Pi Imager because it's very broken on Ubuntu:-

    Sounds like something you should take up with the Ubuntu packagers. I
    maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo eselect >> repository enable salfter && sudo emaint sync -r salfter), and it works like >> a champ.

    More recently, I've migrated my print server (an ancient RPi Model B) from >> Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless. The
    Alpine install needed to be done on a spare Raspberry Pi, but once it was up >> and running with ssh access, I was able to do the rest of the setup over the >> network. Once I had it configured as I wanted it, I brought the MicroSD card
    over to another computer to image it and shipped the image home so I could >> blast it onto an SD card. It's a much lighter-weight system now...could put >> it on a 128MB SD card, if I had one that small. :) The server runs headless, >> with just two printers, a network cable, and a power supply plugged in.


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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Scott Alfter on Thu Feb 1 16:44:32 2024
    On 01/02/2024 16:29, Scott Alfter wrote:
    In article <zQKdnaXu1ZFtpyb4nZ2dnZfqn_udnZ2d@earthlink.com>,
    68g.1499 <68g.1499@etr6.net> wrote:
    On 1/30/24 6:05 PM, Scott Alfter wrote:
    In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
    Chris Green <cl@isbd.net> wrote:
    I can't us Pi Imager because it's very broken on Ubuntu:-

    Sounds like something you should take up with the Ubuntu packagers. I
    maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo eselect >>> repository enable salfter && sudo emaint sync -r salfter), and it works like
    a champ.

    More recently, I've migrated my print server (an ancient RPi Model B) from >>> Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless. The
    Alpine install needed to be done on a spare Raspberry Pi, but once it was up
    and running with ssh access, I was able to do the rest of the setup over the
    network. Once I had it configured as I wanted it, I brought the MicroSD card
    over to another computer to image it and shipped the image home so I could >>> blast it onto an SD card. It's a much lighter-weight system now...could put
    it on a 128MB SD card, if I had one that small. :) The server runs headless,
    with just two printers, a network cable, and a power supply plugged in.


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

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


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


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

    Joseph Goebbels

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to Pancho on Thu Feb 1 21:19:10 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Chris Green on Thu Feb 1 22:56:16 2024
    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?

    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Fri Feb 2 07:15:46 2024
    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:
    In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
    Chris Green  <cl@isbd.net> wrote:
    I can't us Pi Imager because it's very broken on Ubuntu:-

    Sounds like something you should take up with the Ubuntu packagers.  I >>>> maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo
    eselect
    repository enable salfter && sudo emaint sync -r salfter), and it
    works like
    a champ.

    More recently, I've migrated my print server (an ancient RPi Model
    B) from
    Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless.  The >>>> Alpine install needed to be done on a spare Raspberry Pi, but once
    it was up
    and running with ssh access, I was able to do the rest of the setup
    over the
    network.  Once I had it configured as I wanted it, I brought the
    MicroSD card
    over to another computer to image it and shipped the image home so I
    could
    blast it onto an SD card.  It's a much lighter-weight system
    now...could put
    it on a 128MB SD card, if I had one that small. :) The server runs
    headless,
    with just two printers, a network cable, and a power supply plugged in. >>>

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

    It avoids massively long printer cables obviously, when you have a
    pre-existent network of some sort...


      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



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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 68g.1499@3:770/3 to Scott Alfter on Fri Feb 2 02:19:47 2024
    On 2/1/24 11:29 AM, 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.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 68g.1499@3:770/3 to The Natural Philosopher on Fri Feb 2 02:11:30 2024
    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:
    In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
    Chris Green  <cl@isbd.net> wrote:
    I can't us Pi Imager because it's very broken on Ubuntu:-

    Sounds like something you should take up with the Ubuntu packagers.  I
    maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo
    eselect
    repository enable salfter && sudo emaint sync -r salfter), and it
    works like
    a champ.

    More recently, I've migrated my print server (an ancient RPi Model B)
    from
    Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless.  The
    Alpine install needed to be done on a spare Raspberry Pi, but once it
    was up
    and running with ssh access, I was able to do the rest of the setup
    over the
    network.  Once I had it configured as I wanted it, I brought the
    MicroSD card
    over to another computer to image it and shipped the image home so I
    could
    blast it onto an SD card.  It's a much lighter-weight system
    now...could put
    it on a 128MB SD card, if I had one that small. :) The server runs
    headless,
    with just two printers, a network cable, and a power supply plugged in.


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

    It avoids massively long printer cables obviously, when you have a pre-existent network of some sort...


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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 68g.1499@3:770/3 to The Natural Philosopher on Fri Feb 2 02:43:32 2024
    On 2/1/24 11:44 AM, The Natural Philosopher wrote:
    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.


    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Theo on Fri Feb 2 07:47:35 2024
    Theo <theom+news@chiark.greenend.org.uk> wrote:
    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?

    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
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Elvidge@3:770/3 to All on Fri Feb 2 13:01:06 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Anssi Saari@3:770/3 to Scott Alfter on Fri Feb 2 17:13:38 2024
    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to All on Fri Feb 2 14:47:52 2024
    T24gMzEvMDEvMjAyNCAwMzo0MywgNjhnLjE0OTkgd3JvdGU6DQo+ICDCoCAiUG9wdWxhciIg c3lzdGVtcyAtIFdpbi9BbmRyb2lkL01hYyAtIGFyZSBnb2luZyB0byBiZSB0aGUNCj4gIMKg IHByaW1hcnkgdGFyZ2V0cywgYm90cyBhbmQgc3VjaCBvcHRpbWl6ZWQgZm9yIHRoZW0uIExp bnV4DQo+ICDCoCBwcm9wZXIgaXMgdGhlcmUsIGJ1dCBub3Qgc3VwZXItcG9wdWxhciBieSB0 aGUgcGVyY2VudGFnZXMuDQo+ICDCoCBXaW4gaW4gcGFydGljdWxhciBpcyBhIHNlY3VyaXR5 IGRpc2FzdGVyIGFuZCBtb3N0IHVzZXJzDQo+ICDCoCBhcmUga25vdy1ub3RoaW5ncywgYmVz dCB0byBwdXQgZWZmb3J0cyB0aGVyZS4NCg0KTm8sdGhlc2UgZGF5cyB0aGV5IGFyZSBsb29r aW5nIHRvIHJlY3J1aXQgUE9TIENoaW5lc2UgSU9UIHN0dWZmIHJ1bm5pbmcsIA0Kc3VjaCBh cyBzZWN1cml0eSBjYW1lcmFzLCAic21hcnQiIGtpdGNoZW4gYXBwIGxpY2VuY2VzIGFuZCBn b2Qga25vd3MgDQp3aGF0IGVsc2UuDQoNCldoYXQgdGhlc2UgdGhpbmdzIGhhdmUgaW4gY29t bW9uIGlzIHJ1bm5pbmcgYSB2ZXJzaW9uIG9mIExpbnV4IHdpdGggdmVyeSANCnBvb3Igc2Vj dXJpdHksIHN1Y2ggYXMgaGFyZGNvZGVkIHBhc3N3b3JkcywgaW5zZWN1cmUgcHJvdG9jb2xz LCBubyANCmZpcmV3YWxscyBvciBpbnRydXNpb24gZGV0ZWN0aW9uLCBhbmQgbm8gb25lIGxv Z2dlZCBpbiBydW5uaW5nIHRvb2xzIHRvIA0Kc2VlIHdoeSB0aGV5IGFyZSBzbG93IG9yIGFy ZSBzZW5kaW5nIGRhdGEgYWxsIG92ZXIgdGhlIGludGVybmV0IChldmVuIA0KbW9yZSB0aGFu IHRoZSB0ZWxlbWV0cnkgdGhhbiB0aGV5IGFyZSBtZWFudCB0byBzZW5kIGJhY2sgdG8gdGhl IG1vdGhlcnNoaXApLg0KDQpEb24ndCBtYWtlIHlvdXIgUmFzcGJlcnJ5IGFzIGVhc3kgdG8g Y3JhY2sgYXMgdGhlc2UgdGhpbmdzIQ0KDQotLS1kcnVjaw0KDQo=

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Adam Funk@3:770/3 to Charlie Gibbs on Fri Feb 2 16:10:10 2024
    On 2024-01-31, Charlie Gibbs wrote:

    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.

    I remember laughing at that at too.


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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Scott Alfter@3:770/3 to 68g.1499@etr6.net on Fri Feb 2 16:16:45 2024
    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Adam Funk@3:770/3 to Theo on Fri Feb 2 16:09:02 2024
    On 2024-02-01, Theo wrote:

    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Scott Alfter@3:770/3 to anssi.saari@usenet.mail.kapsi.fi on Fri Feb 2 16:29:32 2024
    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Scott Alfter@3:770/3 to 68g.1499@etr6.net on Fri Feb 2 16:34:48 2024
    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 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.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Scott Alfter on Fri Feb 2 19:47:49 2024
    On 02/02/2024 16:29, Scott Alfter wrote:
    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 68g.1499@3:770/3 to Scott Alfter on Sat Feb 3 04:14:11 2024
    On 2/2/24 11:16 AM, Scott Alfter wrote:
    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.


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

    But, if you want it that way ...

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 68g.1499@3:770/3 to The Natural Philosopher on Sat Feb 3 04:19:25 2024
    On 2/2/24 2:15 AM, The Natural Philosopher wrote:
    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:
    In article <k4fd8k-d8d71.ln1@esprimo.zbmc.eu>,
    Chris Green  <cl@isbd.net> wrote:
    I can't us Pi Imager because it's very broken on Ubuntu:-

    Sounds like something you should take up with the Ubuntu packagers.  I >>>>> maintain a Gentoo ebuild for rpi-imager (it's in my overlay...sudo
    eselect
    repository enable salfter && sudo emaint sync -r salfter), and it
    works like
    a champ.

    More recently, I've migrated my print server (an ancient RPi Model
    B) from
    Raspbia^H^H^H^H^H^H^HRPi OS to Alpine, and it's running headless.  The >>>>> Alpine install needed to be done on a spare Raspberry Pi, but once
    it was up
    and running with ssh access, I was able to do the rest of the setup
    over the
    network.  Once I had it configured as I wanted it, I brought the
    MicroSD card
    over to another computer to image it and shipped the image home so
    I could
    blast it onto an SD card.  It's a much lighter-weight system
    now...could put
    it on a 128MB SD card, if I had one that small. :) The server runs
    headless,
    with just two printers, a network cable, and a power supply plugged
    in.


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

    It avoids massively long printer cables obviously, when you have a
    pre-existent network of some sort...


       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

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 68g.1499@3:770/3 to Chris Elvidge on Sat Feb 3 04:22:40 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 68g.1499@3:770/3 to Scott Alfter on Sat Feb 3 04:30:52 2024
    On 2/2/24 11:34 AM, Scott Alfter wrote:
    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 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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to Richard Kettlewell on Sun Feb 4 14:47:19 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to druck on Sun Feb 4 14:53:16 2024
    On 01/02/2024 21:19, druck wrote:
    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.


    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 68g.1499@3:770/3 to The Natural Philosopher on Tue Feb 6 01:50:34 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to All on Wed Feb 7 11:07:46 2024
    T24gMDIvMDIvMjAyNCAxNDo0NywgZHJ1Y2sgd3JvdGU6DQo+IE9uIDMxLzAxLzIwMjQgMDM6 NDMsIDY4Zy4xNDk5IHdyb3RlOg0KPj4gwqDCoCAiUG9wdWxhciIgc3lzdGVtcyAtIFdpbi9B bmRyb2lkL01hYyAtIGFyZSBnb2luZyB0byBiZSB0aGUNCj4+IMKgwqAgcHJpbWFyeSB0YXJn ZXRzLCBib3RzIGFuZCBzdWNoIG9wdGltaXplZCBmb3IgdGhlbS4gTGludXgNCj4+IMKgwqAg cHJvcGVyIGlzIHRoZXJlLCBidXQgbm90IHN1cGVyLXBvcHVsYXIgYnkgdGhlIHBlcmNlbnRh Z2VzLg0KPj4gwqDCoCBXaW4gaW4gcGFydGljdWxhciBpcyBhIHNlY3VyaXR5IGRpc2FzdGVy IGFuZCBtb3N0IHVzZXJzDQo+PiDCoMKgIGFyZSBrbm93LW5vdGhpbmdzLCBiZXN0IHRvIHB1 dCBlZmZvcnRzIHRoZXJlLg0KPiANCj4gTm8sdGhlc2UgZGF5cyB0aGV5IGFyZSBsb29raW5n IHRvIHJlY3J1aXQgUE9TIENoaW5lc2UgSU9UIHN0dWZmIHJ1bm5pbmcsIA0KPiBzdWNoIGFz IHNlY3VyaXR5IGNhbWVyYXMsICJzbWFydCIga2l0Y2hlbiBhcHAgbGljZW5jZXMgYW5kIGdv ZCBrbm93cyANCj4gd2hhdCBlbHNlLg0KDQpOb3QgZXZlbiB5b3VyIHRvb3RoYnJ1c2ggaXMg c2FmZSENCg0KaHR0cHM6Ly93d3cudG9tc2hhcmR3YXJlLmNvbS9uZXR3b3JraW5nL3RocmVl LW1pbGxpb24tbWFsd2FyZS1pbmZlY3RlZC1zbWFydC10b290aGJydXNoZXMtdXNlZC1pbi1z d2lzcy1kZG9zLWF0dGFja3MtYm90bmV0LWNhdXNlcy1taWxsaW9ucy1vZi1ldXJvcy1pbi1k YW1hZ2VzDQoNCi0tLWRydWNrDQoNCg==

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to druck on Wed Feb 7 12:26:35 2024
    druck <news@druck.org.uk> wrote:
    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

    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)