• Limiting attack surface for Debian sshd

    From Marc SCHAEFER@21:1/5 to All on Fri Apr 11 20:20:01 2025
    Hello,

    systemd dependancies that are activated on a Debian system imply a lot
    of library injections into sshd, much more than the stock OpenBSD ssh.

    To avoid this, there seem to be two approaches:

    - remove those dependancies (see below)

    - confine the impact of those dependancies, as proposed
    by some developpers, in having those dependancies confined
    (not examined here)

    To solve this, I could use a Bastion host with a limited, non Debian,
    OS, or I could recompile the OpenSSH package on Debian with options
    disabled.

    Doing the latter, I have much more dependancies (**)

    4d3
    < libcom_err.so.2
    9,18d7
    < libgcrypt.so.20
    < libgpg-error.so.0
    < libgssapi_krb5.so.2
    < libk5crypto.so.3
    < libkeyutils.so.1
    < libkrb5.so.3
    < libkrb5support.so.0
    < liblz4.so.1
    < liblzma.so.5
    < libnsl.so.2
    22,23d10
    < libresolv.so.2
    < librt.so.1
    25,26d11
    < libsystemd.so.0
    < libtirpc.so.3
    28d12
    < libwrap.so.0
    30d13
    < libzstd.so.1

    What do you think about this approach?

    Thank you for your comments.


    (*) on Debian bullseye:

    mkdir /tmp/tt
    cd /tmp/tt

    apt-get source openssh

    cd openssh-8.4p1/

    # openbsd-doc does not apply cleanly after
    sed -i '/^systemd-readiness.patch/d;/^restore-tcp-wrappers.patch/d;/^openbsd-docs.patch/d' debian/patches/series
    rm debian/patches/{systemd-readiness.patch,restore-tcp-wrappers.patch,openbsd-docs.patch}

    patch debian/rules <<'EOF'

    schaefer@reliant:/tmp/tt/openssh-8.4p1$ diff -uP debian/rules.ORIG debian/rules --- debian/rules.ORIG 2025-04-11 19:35:13.568132105 +0200
    +++ debian/rules 2025-04-11 19:37:01.355078815 +0200
    @@ -73,20 +73,16 @@
    confflags_udeb := $(confflags)

    # Options specific to the deb build.
    -confflags += --with-tcp-wrappers
    confflags += --with-pam
    confflags += --with-libedit
    -confflags += --with-kerberos5=/usr
    confflags += --with-ssl-engine
    ifeq ($(DEB_HOST_ARCH_OS),linux)
    confflags += --with-selinux
    confflags += --with-audit=linux
    -confflags += --with-systemd
    confflags += --with-security-key-builtin
    endif

    -# The deb build wants xauth; the udeb build doesn't.
    -confflags += --with-xauth=/usr/bin/xauth
    +confflags += --without-xauth
    confflags_udeb += --without-xauth

    # Default paths. The udeb build has /usr/games removed.
    EOF

    # -b: avoid source package creation, changelog, etc
    dpkg-buildpackage -b -rfakeroot -us -uc


    (**) demo:

    mkdir /tmp/tt2
    cd /tmp/tt2

    dpkg-deb -x ../tt/openssh-server_*.deb .

    diff <(ldd /usr/sbin/sshd | awk '{print $1;}'
  • From Dan Ritter@21:1/5 to Marc SCHAEFER on Fri Apr 11 20:40:01 2025
    Marc SCHAEFER wrote:

    To avoid this, there seem to be two approaches:

    - remove those dependancies (see below)

    - confine the impact of those dependancies, as proposed
    by some developpers, in having those dependancies confined
    (not examined here)

    To solve this, I could use a Bastion host with a limited, non Debian,
    OS, or I could recompile the OpenSSH package on Debian with options
    disabled.

    What do you think about this approach?

    It's fine, but it changes your methodology from "the Debian
    Security Team works for me and supplies new packages pretty
    quickly" to "I need to be my own security team, and understand
    what's going on with each upstream change."

    Not everyone wants that, but Debian should (and does) provide
    the tools you need to do it your way.

    -dsr-

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Stone@21:1/5 to Marc SCHAEFER on Fri Apr 11 21:20:01 2025
    On Fri, Apr 11, 2025 at 08:12:14PM +0200, Marc SCHAEFER wrote:
    To solve this, I could use a Bastion host with a limited, non Debian,
    OS, or I could recompile the OpenSSH package on Debian with options
    disabled.

    I'd suggest just backporting the currrent version from sid rather than
    trying to modify the one in bullseye, as the most significant changes
    were already made when gssapi was split into a separate package. (I'd
    also recommend upgrading to bookworm.) You can either remove the build-dependency on dh-sequence-movetousr or use a backported version of debhelper.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Smith@21:1/5 to Marc SCHAEFER on Fri Apr 11 22:10:01 2025
    Hi,

    On Fri, Apr 11, 2025 at 08:12:14PM +0200, Marc SCHAEFER wrote:
    systemd dependancies that are activated on a Debian system imply a lot
    of library injections into sshd, much more than the stock OpenBSD ssh.

    To avoid this, there seem to be two approaches:

    - remove those dependancies (see below)

    - confine the impact of those dependancies, as proposed
    by some developpers, in having those dependancies confined
    (not examined here)

    To solve this, I could use a Bastion host with a limited, non Debian,
    OS, or I could recompile the OpenSSH package on Debian with options
    disabled.

    […]

    What do you think about this approach?

    I think you're wasting your time and should not have sshd listen on the
    public Internet at all, instead VPN in to your network and only have
    sshd available on the inside.

    Thanks,
    Andy

    --
    https://bitfolk.com/ -- No-nonsense VPS hosting

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to Andy Smith on Sat Apr 12 07:30:01 2025
    On Fri, Apr 11, 2025 at 07:59:40PM +0000, Andy Smith wrote:
    Hi,

    On Fri, Apr 11, 2025 at 08:12:14PM +0200, Marc SCHAEFER wrote:
    systemd dependancies that are activated on a Debian system imply a lot
    of library injections into sshd, much more than the stock OpenBSD ssh.

    [...]

    What do you think about this approach?

    I'd be all for it, actually.

    I think you're wasting your time and should not have sshd listen on the public Internet at all, instead VPN in to your network and only have
    sshd available on the inside.

    You already stated this. I don't think it is right, for two reasons:

    - you didn't explain how "a VPN's" mechanism is inherently more
    secure than sshd's, given that their mechanisms are all pretty
    similar.
    - Your category "a VPN" is hopelessly too broad (that's why I
    put it in quotes). What do you mean? IPSec? OpenVPN? Wireguard?
    CIPE? Some proprietary thing (there are loads of them)?

    Since security depends critically on implementation details and
    the dedication of the group behind the software, the above is quite
    relevant.

    So, share your wisdom with us: what makes ssh less secure than
    "a VPN"?

    Cheers
    --
    t

    -----BEGIN PGP SIGNATURE-----

    iFwEABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ/n4+gAKCRAFyCz1etHa RplcAJj6Sh5zrBI/wMnIUAIJRuv0K14JAJ4/nZnMkfika4E5IFnTj4xIsgbIow==
    =W1um
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to jeremy ardley on Sat Apr 12 07:50:01 2025
    On Sat, Apr 12, 2025 at 01:32:06PM +0800, jeremy ardley wrote:

    On 12/4/25 13:24, [email protected] wrote:
    So, share your wisdom with us: what makes ssh less secure than
    "a VPN"?


    It's quite simple. If you have a VPN exposed to the internet and an ssh service then you have two attack surfaces in parallel. Breach either one and you breach the system

    What if you don't even need the VPN (as is often the case)?

    Remember: simplicity usually helps security, because the admin can
    understand the system better.

    Cheers
    --
    t

    -----BEGIN PGP SIGNATURE-----

    iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ/n9pAAKCRAFyCz1etHa Rj2hAJ9LpThQKdRqpbZFWGTrMCyv8+puFwCdHjYgwYOGqCHU9yPyfRl0vWVFZto=
    =f8J3
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc SCHAEFER@21:1/5 to [email protected] on Sat Apr 12 09:50:01 2025
    Hello,

    Jumping into your interesting ssh vs VPN discussion:

    On Sat, Apr 12, 2025 at 07:24:17AM +0200, [email protected] wrote:
    - you didn't explain how "a VPN's" mechanism is inherently more
    secure than sshd's, given that their mechanisms are all pretty
    similar.

    I agree. Especially since the idea here is to create a jump host,
    it has all advantages of a VPN (can be on a separate host,
    can be handled with firewall rules), much the same.

    I am also a fan of VPNs, BTW. Sometimes they are very
    useful too. But sometimes, yes, I think they are overblown
    compared to a "simple" ssh server. They may however offer
    more features in some cases (namely UDP tunnelling and
    maybe simpler integrations on non standard OSes like Microsoft,
    that I don't use).

    - Your category "a VPN" is hopelessly too broad (that's why I
    put it in quotes). What do you mean? IPSec? OpenVPN? Wireguard?
    CIPE? Some proprietary thing (there are loads of them)?

    Yes.

    On the subject of attack surfaces, let's talk about OpenVPN:

    schaefer@reliant:~$ ldd /usr/sbin/openvpn
    linux-vdso.so.1 (0x00007ffedb3b3000)
    liblzo2.so.2 => /lib/x86_64-linux-gnu/liblzo2.so.2 (0x00007fa13453a000)
    liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fa134517000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa1344f5000)
    libpkcs11-helper.so.1 => /lib/x86_64-linux-gnu/libpkcs11-helper.so.1 (0x00007fa1344d6000)
    libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007fa134443000)
    libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007fa13414f000)
    libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007fa134098000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa134092000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa133ebe000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa13465d000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fa133eb4000)
    liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fa133e8c000)
    libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007fa133db1000)
    libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007fa133c8f000)
    libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fa133c69000)

    It looks a bit narrower than stock sshd on Debian, but you can find the
    same "interesting" libs. Also, I wonder if OpenVPN has similar
    privilege separation as ssh. They seem to have though about it: https://community.openvpn.net/openvpn/wiki/PrivilegeSeparation
    but it does not look as streamlined as SSH (I might be wrong).

    NB: however, some recent OpenVPN releases might also run with a kernel
    module, which augments the attack surface considerably -- I don't use it
    yet, but you might find it necessary for high workloads (stock OpenVPN is 1-core for compression/encryption). SSH is one-process-per-user,
    so it should scale better in my workloads.

    Wireguard, for example, is mostly kernel-side BTW.

    I do not assume those kernel codes are unsafe, I am pretty sure they
    have audited them. It just makes the attack surface much bigger.

    Since security depends critically on implementation details and
    the dedication of the group behind the software, the above is quite
    relevant.

    Agree.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to Marc SCHAEFER on Sat Apr 12 10:10:01 2025
    On Sat, Apr 12, 2025 at 09:39:53AM +0200, Marc SCHAEFER wrote:
    Hello,

    Jumping into your interesting ssh vs VPN discussion:

    [...]

    Thanks for all those interesting details.

    To sum up, I'd concur with Andy in one point: *if* you are running
    a VPN anyway, it's better to hide you SSH behind that.

    Otherwise, I tend to disagree. I'd expect OpenSSH to be far better
    audited...

    I do not assume those kernel codes are unsafe, I am pretty sure they
    have audited them. It just makes the attack surface much bigger.

    ... than probably anything else out there (available to mere mortals,
    not in NSA'a deep belly or any other mythical beast). Of course, it
    gets its share of auditing love by the Bad Actors, too, so there you
    are.

    Setting up a VPN to "just" protect an SSH access seems like a bad
    use of resources to me. Invest those in your SSH daemon's setup (misconfiguration being probably the most widespread source of
    security flaws).

    But... it's always a bet, since no one of us knows everything.

    Cheers
    --
    t

    -----BEGIN PGP SIGNATURE-----

    iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ/ofjgAKCRAFyCz1etHa RgO+AJ9jIQsV5cRq9Zu5qqssqaAuE05IeQCeJU8TF7NAUurzy573MJoQas/jlcg=
    =JmCP
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Smith@21:1/5 to Marc SCHAEFER on Sat Apr 12 11:10:01 2025
    Hi,

    On Sat, Apr 12, 2025 at 09:39:53AM +0200, Marc SCHAEFER wrote:
    sometimes, yes, I think [VPNs] are overblown compared to a "simple"
    ssh server.

    I think that a decent modern VPN solution is much simpler than OpenSSH
    and especially when your alternative is recompiling OpenSSH to remove dependencies that you think you don't need.

    Wireguard, for example, is mostly kernel-side BTW.

    I do not assume those kernel codes are unsafe, I am pretty sure they
    have audited them. It just makes the attack surface much bigger.

    I am pretty confident that the amount of code that can be reached by
    strange packets from the Internet side is going to be a lot smaller with WireGuard.

    It's going to be quite difficult to prove either way though, so let's
    just agree to disagree.

    Thanks,
    Andy

    --
    https://bitfolk.com/ -- No-nonsense VPS hosting

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to Lee on Sat Apr 12 17:00:01 2025
    On Sat, Apr 12, 2025 at 09:29:41AM -0400, Lee wrote:
    On Sat, Apr 12, 2025 at 1:44 AM tomas wrote:

    On Sat, Apr 12, 2025 at 01:32:06PM +0800, jeremy ardley wrote:

    On 12/4/25 13:24, tomas wrote:
    So, share your wisdom with us: what makes ssh less secure than
    "a VPN"?


    It's quite simple. If you have a VPN exposed to the internet and an ssh service then you have two attack surfaces in parallel. Breach either one and
    you breach the system

    What if you don't even need the VPN (as is often the case)?

    Is port 22 the only thing you've got open? What does
    sudo ss -anltup
    show?

    My host "out there" has quite a few more ports open, but they
    are supposed to be (http, https, smtp, imaps and a few others :-)

    I've got a lot more than SSH/22 open, so if I was going to put this
    machine on the internet I'd want most of those ports turned off.

    My laptop has one to two handful of these, depending on what I'm
    currently playing with.

    Cheers
    --
    t

    -----BEGIN PGP SIGNATURE-----

    iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ/p9NgAKCRAFyCz1etHa RjkrAJ0TRb6YdezM0AW8sZUimxCPa3YupgCfdiVHo8jevLb1TocLlpIKmhvF9sY=
    =+69W
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc SCHAEFER@21:1/5 to All on Sun Apr 13 17:20:01 2025
    Hello,

    would you be open to using another implementation of an ssh server?
    If so, it would be a third approach:

    Yes, it would be. It might help with the attack surface issue of
    current sshd.

    However, I would guess that most of the alternative to OpenSSH are
    using libssh, which also had some issues.

    I presumably would trust a stripped-down OpenSSH more than anything
    based on libssh, but I might be wrong.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Monnier@21:1/5 to All on Sun Apr 13 17:40:01 2025
    My laptop has one to two handful of these, depending on what I'm
    currently playing with.
    I taking a class at the local library; my laptop has avahi and cups
    ports open .. which I'm not thrilled about but I like the zero-conf
    printing ability.

    Why do you need cups ports open to print?
    I understand you need the cups port to be open on the side of the
    printer (or print-server), but not on the side of the machine that sends
    the print job.
    Am I missing something?


    Stefan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc SCHAEFER@21:1/5 to Lee on Sun Apr 13 17:20:02 2025
    Hello,

    On Sun, Apr 13, 2025 at 10:59:45AM -0400, Lee wrote:
    I taking a class at the local library; my laptop has avahi and cups
    ports open .. which I'm not thrilled about but I like the zero-conf
    printing ability.

    If you
    sudo systemctl disable cups # and maybe others

    then, you can do

    sudo systemctl start cups

    whenever you require cups (and stop it afterwards).

    I rarely print documents nowadays.

    You could also install a local firewall, but the goal with CUPS is
    presumably to let it talk to other systems.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nate Bargmann@21:1/5 to Stefan Monnier on Sun Apr 13 20:30:01 2025
    * On 2025 13 Apr 10:38 -0500, Stefan Monnier wrote:
    My laptop has one to two handful of these, depending on what I'm
    currently playing with.
    I taking a class at the local library; my laptop has avahi and cups
    ports open .. which I'm not thrilled about but I like the zero-conf printing ability.

    Why do you need cups ports open to print?
    I understand you need the cups port to be open on the side of the
    printer (or print-server), but not on the side of the machine that sends
    the print job.
    Am I missing something?

    No.

    On my systems CUPS only listens on localhost:631. The firewall blocks
    outside access for good measure. For avahi, it is listening on 0.0.0.0
    and localhost. Firewalling should be fine for discovering other devices
    and blocking discovery of the firewalled device, though I am far from an expert.

    - Nate

    --
    "The optimist proclaims that we live in the best of all
    possible worlds. The pessimist fears this is true."
    Web: https://www.n0nb.us
    Projects: https://github.com/N0NB
    GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819


    -----BEGIN PGP SIGNATURE-----

    iF0EABECAB0WIQSC1k9rDmfNQfaJu6b7LFEw1VqIGQUCZ/v6sQAKCRD7LFEw1VqI GSB5AKCdKg8rnvF9Ss6PawSNVWVzBqs1cgCdEGm+Y6HBB0BYil9QbSKldKPkcno=
    =MG6W
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc SCHAEFER@21:1/5 to All on Mon Apr 14 14:10:02 2025
    I wrote:

    If you
    sudo systemctl disable cups # and maybe others

    Actually, if you follow the discussion, the CUPS Bonjour auto-discovery

    - it presumably handled by the cups-browsed package
    (you can uninstall it, or systemctl disable it,
    if you don't want printer auto-detection on your
    network)

    - it could also be handled by mDNS (?)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc SCHAEFER@21:1/5 to didier gaumet on Mon Apr 14 14:00:06 2025
    Hello,

    On Sun, Apr 13, 2025 at 06:24:50PM +0200, didier gaumet wrote:
    didier@hp-notebook14:~$ ldd /usr/sbin/tinysshd
    linux-vdso.so.1 (0x00007ffdb29f7000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f54a996c000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f54a9c2e000)

    that seems to me pretty minimal ;-)

    Yes! On the (dynamic) dependancy side it seems ideal.

    So it means it's a reimplementation of the SSH server, not using libssh?
    (or it's statically compiled, which could be worse?)

    However: it could mean it's much less scrutinized than libssh, which in turn "looks" less scrutinized than OpenSSH ...

    It looks it has very few lines of code, which is good:

    https://github.com/janmojzis/tinyssh

    However, it does not seem to support port forwarding, which can be
    handy on a jump host ...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Purgert@21:1/5 to Marc SCHAEFER on Mon Apr 14 14:40:01 2025
    On Apr 14, 2025, Marc SCHAEFER wrote:
    I wrote:

    If you
    sudo systemctl disable cups # and maybe others

    Actually, if you follow the discussion, the CUPS Bonjour auto-discovery

    - it presumably handled by the cups-browsed package
    (you can uninstall it, or systemctl disable it,
    if you don't want printer auto-detection on your
    network)

    - it could also be handled by mDNS (?)

    Yep, 'cups-browsed' is the mDNS listener service (plugin for avahi?) so
    that cups can find printers announcing themselves via mDNS.

    --
    |_|O|_|
    |_|_|O| Github: https://github.com/dpurgert
    |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmf8/9cACgkQbWVw5Uzn KGDMsw//Rrxx3KRhjY8ZO1jQkmF15U00foqQ6MNTvKFy1yhT2L9dXsomYaygmFd5 F6PWbshyaceq96msWrVRii5DyJHqrPC1Urf+ed9Cy/LUQ8tjXFAuheIOGzz1z9Ff 6KlHNsZKVSilDU7q/YhH92pk2+5cT5Y/f88hny69B3g6/WAjaG+WU0ZydPUUKSiW RXWevFrTot6SuRerUazteaDwTv023FArKs18eQFTjxWXAB6XnPvYMc7F19Ai8hpf caGm+d6EUpllKfBF16NDzf7OmO9K0cqeB9JXlJqmK3oozmH1MkXc1vybNZfsaZgT 4oF1ni4Q6Nsee/bJXb6sEZtPeIzlZ+KiuVeI9RVqN8rSbP6/coWIL291H8vkaC2z yHqsDrNYeO9WxdFwdN7lDzCATTDxJxNIxOUp0gzTk2dWT1gfvNfr53s8Qa3QJlXM jyZQJ72QWK88DLlra5YYbvuNMtjuonD87xbfIkAYLbdKd80xHIXURvIIUqhu975V S8VPLb+k6w0Wj6k4Bs/+8MqySn7j7hIw5QHokaRoQ5/22aQQZ8XBPlto6WbL4iZq smq++Yd+m6Y4rv73MQswDfqqTTLD/6DtqkjSRMaptwDTXKcuydKfVVpwx4O3FF+X ufXdK1jv/g/Yi2nDojFb1vdksR0+g5uq/9MiO4ZUXVLCqyhrgM4=
    =gvvA
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Us
  • From Marc SCHAEFER@21:1/5 to didier gaumet on Mon Apr 14 18:00:01 2025
    On Mon, Apr 14, 2025 at 03:08:11PM +0200, didier gaumet wrote:
    please take all that precedes with a grain of salt: I do not install and set up ssh servers :-)

    All input is welcome, thank you.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Paoli@21:1/5 to [email protected] on Mon Apr 14 21:30:02 2025
    What systemd dependencies? :-)

    # readlink /proc/1/exe /sbin && dpkg -S /sbin/init && cat
    /etc/debian_version && more /etc/apt/preferences.d/* | cat
    /usr/sbin/init
    usr/sbin

    sysvinit-core: /sbin/init
    12.10
    ::::::::::::::
    /etc/apt/preferences.d/98init
    ::::::::::::::
    Explanation: Avoid unintended installation of systemd-sysv.
    Explanation: init can be provided by: systemd-sysv | sysvinit-core
    Package: systemd-sysv
    Pin: version *
    Pin-Priority: -1

    ::::::::::::::
    /etc/apt/preferences.d/99init
    ::::::::::::::
    Explanation: Avoid unintended installation of systemd
    Explanation: Note that systemd doesn't require systemd-sysv (systemd's Explanation: init system).
    Package: systemd
    Pin: version *
    Pin-Priority: -1

    #

    On Fri, Apr 11, 2025 at 11:12 AM Marc SCHAEFER <[email protected]> wrote:

    Hello,

    systemd dependancies that are activated on a Debian system imply a lot
    of library injections into sshd, much more than the stock OpenBSD ssh.

    To avoid this, there seem to be two approaches:

    - remove those dependancies (see below)

    - confine the impact of those dependancies, as proposed
    by some developpers, in having those dependancies confined
    (not examined here)

    To solve this, I could use a Bastion host with a limited, non Debian,
    OS, or I could recompile the OpenSSH package on Debian with options
    disabled.

    Doing the latter, I have much more dependancies (**)

    4d3
    < libcom_err.so.2
    9,18d7
    < libgcrypt.so.20
    < libgpg-error.so.0
    < libgssapi_krb5.so.2
    < libk5crypto.so.3
    < libkeyutils.so.1
    < libkrb5.so.3
    < libkrb5support.so.0
    < liblz4.so.1
    < liblzma.so.5
    < libnsl.so.2
    22,23d10
    < libresolv.so.2
    < librt.so.1
    25,26d11
    < libsystemd.so.0
    < libtirpc.so.3
    28d12
    < libwrap.so.0
    30d13
    < libzstd.so.1

    What do you think about this approach?

    Thank you for your comments.


    (*) on Debian bullseye:

    mkdir /tmp/tt
    cd /tmp/tt

    apt-get source openssh

    cd openssh-8.4p1/

    # openbsd-doc does not apply cleanly after
    sed -i '/^systemd-readiness.patch/d;/^restore-tcp-wrappers.patch/d;/^openbsd-docs.patch/d' debian/patches/series
    rm debian/patches/{systemd-readiness.patch,restore-tcp-wrappers.patch,openbsd-docs.patch}

    patch debian/rules <<'EOF'

    schaefer@reliant:/tmp/tt/openssh-8.4p1$ diff -uP debian/rules.ORIG debian/rules
    --- debian/rules.ORIG 2025-04-11 19:35:13.568132105 +0200
    +++ debian/rules 2025-04-11 19:37:01.355078815 +0200
    @@ -73,20 +73,16 @@
    confflags_udeb := $(confflags)

    # Options specific to the deb build.
    -confflags += --with-tcp-wrappers
    confflags += --with-pam
    confflags += --with-libedit
    -confflags += --with-kerberos5=/usr
    confflags += --with-ssl-engine
    ifeq ($(DEB_HOST_ARCH_OS),linux)
    confflags += --with-selinux
    confflags += --with-audit=linux
    -confflags += --with-systemd
    confflags += --with-security-key-builtin
    endif

    -# The deb build wants xauth; the udeb build doesn't.
    -confflags += --with-xauth=/usr/bin/xauth
    +confflags += --without-xauth
    confflags_udeb += --without-xauth

    # Default paths. The udeb build has /usr/games removed.
    EOF

    # -b: avoid source package creation, changelog, etc
    dpkg-buildpackage -b -rfakeroot -us -uc


    (**) demo:

    mkdir /tmp/tt2
    cd /tmp/tt2

    dpkg-deb -x ../tt/openssh-server_*.deb .

    diff <(ldd /usr/sbin/sshd | awk '{print $1;}' | sort) <(ldd usr/sbin/sshd | awk '{print $1;}' | sort)


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to Michael Paoli on Tue Apr 15 08:30:01 2025
    On Mon, Apr 14, 2025 at 12:20:34PM -0700, Michael Paoli wrote:
    What systemd dependencies? :-)

    Thanks for reminding us that Debian is (more or less) viable
    without systemd (I try to keep my daily driver that way, too).

    But the original poster has another, valid concern. I think
    the best illustration is given by that xz vulnerability [1]
    which was so elaborate that it was certainly introduced
    intentionally.

    The dependency of OpenSSH on the xz library was introduced
    in Debian (and RedHat and...) by linking to libsystemd things,
    to make the user's lives more comfortable (socket activation,
    what have you).

    So even without systemd, just with the Debian binary of the
    OpenSSH server (patched to work well with systemd), you'd
    have been exposed.

    Cheers

    [1] https://en.wikipedia.org/wiki/XZ_Utils_backdoor
    --
    tomás

    -----BEGIN PGP SIGNATURE-----

    iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ/38AgAKCRAFyCz1etHa RnyqAJ9KLrdaMwBhxmgRy1B1clUzRfYisACeKsQ0qiY1JgDgYxaUvtNaYhgmigI=
    =7ezF
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michel Verdier@21:1/5 to Lee on Wed Apr 16 09:10:01 2025
    On 2025-04-15, Lee wrote:

    If I turn the cups service back on I can print:

    $ sudo systemctl start cups.service

    $ lp -d Canon_MG3600_series check-for-updates.sh
    request id is Canon_MG3600_series-4 (1 file(s))

    cupsd should listen on ports but only on localhost:

    # ss -nltup | grep cups
    tcp LISTEN 0 0 127.0.0.1:631 0.0.0.0:* users:(("cupsd",pid=30001,fd=8))
    tcp LISTEN 0 0 [::1]:631 *:* users:(("cupsd",pid=30001,fd=7))

    If this is not the case you should put in /etc/cups/cupsd.conf
    Listen localhost:631
    Listen /run/cups/cups.sock

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Erwan David@21:1/5 to Lee on Wed Apr 16 09:20:02 2025
    On Wed, Apr 16, 2025 at 03:16:29AM CEST, Lee <[email protected]> said:
    On Mon, Apr 14, 2025 at 10:27 AM Dan Purgert wrote:

    On Apr 14, 2025, Marc SCHAEFER wrote:
    I wrote:

    If you
    sudo systemctl disable cups # and maybe others

    Actually, if you follow the discussion, the CUPS Bonjour auto-discovery

    - it presumably handled by the cups-browsed package
    (you can uninstall it, or systemctl disable it,
    if you don't want printer auto-detection on your
    network)

    - it could also be handled by mDNS (?)

    Yep, 'cups-browsed' is the mDNS listener service (plugin for avahi?) so that cups can find printers announcing themselves via mDNS.

    I'm not sure I understand, but
    $ sudo systemctl stop cups.service

    $ lp -d Canon_MG3600_series check-for-updates.sh
    lp: Bad file descriptor

    You stopped cups (ie the whole printing system), not cups-browsed (the mDNS listener to get printers of the local
    network announcing themselves by Zeroconf)

    --
    Erwan David

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gene heskett@21:1/5 to Erwan David on Sat Apr 19 05:10:01 2025
    On 4/16/25 03:14, Erwan David wrote:
    On Wed, Apr 16, 2025 at 03:16:29AM CEST, Lee <[email protected]> said:
    On Mon, Apr 14, 2025 at 10:27 AM Dan Purgert wrote:
    On Apr 14, 2025, Marc SCHAEFER wrote:
    I wrote:

    If you
    sudo systemctl disable cups # and maybe others
    Actually, if you follow the discussion, the CUPS Bonjour auto-discovery >>>>
    - it presumably handled by the cups-browsed package
    (you can uninstall it, or systemctl disable it,
    if you don't want printer auto-detection on your
    network)

    - it could also be handled by mDNS (?)
    Yep, 'cups-browsed' is the mDNS listener service (plugin for avahi?) so
    that cups can find printers announcing themselves via mDNS.
    I'm not sure I understand, but
    $ sudo systemctl stop cups.service

    $ lp -d Canon_MG3600_series check-for-updates.sh
    lp: Bad file descriptor
    You stopped cups (ie the whole printing system), not cups-browsed (the mDNS listener to get printers of the local
    network announcing themselves by Zeroconf)

    Which brings up the fact that if cups-browsed is present, it disables
    the factory drivers which run my 2 brother printers flawlessly, every
    feature listed on the boxes Just Works,  with the cups flavor of cups
    drivers which are grossly broken and have been for a decade or more. I
    lose tray choice, color is weak and afu on my color inkjet and my B&W
    laser loses duplex and doesn't properly respond to a formfeed.

    Cheers, Gene Heskett, CET.

    --
    "There are four boxes to be used in defense of liberty:
    soap, ballot, jury, and ammo. Please use in that order."
    -Ed Howdershelt (Author, 1940)
    If we desire respect for the law, we must first make the law respectable.
    - Louis D. Brandeis

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to Andrew M.A. Cater on Sat Apr 19 20:10:01 2025
    On Sat, Apr 19, 2025 at 05:35:51PM +0000, Andrew M.A. Cater wrote:

    [...]

    Hi Gene,

    This is probably off topic for the subject of the thread above but -

    You always claim that stuff is grossly broken: in this instance, CUPS
    is probably *not* broken. The problem is that the free drivers - which
    are essentially all that Debian can ship - are less functional than the proprietary drivers shipped by Brother.

    Exactly. The bug /is/ the proprietary driver. I wouldn't buy such a
    printer.

    In fact, I've looked at some and decided I don't need a printer. My room
    in a shared flat is small, and they all seem to have gone to the dark
    side. Not worth the hassle.

    From time to time I try to "fix" my flatmate's printer and am reminded
    every time (phone home: rly?) why I'm happy without.

    The couple of times I need to print something (that very rare snail mail,
    for example), I go to that stationery shop, ten minutes bike ride. It's
    worth it, and the shop owner is awfully nice to boot.

    Cheers
    --
    t

    -----BEGIN PGP SIGNATURE-----

    iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCaAPlegAKCRAFyCz1etHa RnXmAJ9316U8nIS4Q8tpRICBNR5nw9Jb8ACbBb7hfbLY/BV/zUAvcygyFK+mgcY=
    =UWFa
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrew M.A. Cater@21:1/5 to gene heskett on Sat Apr 19 19:40:01 2025
    On Fri, Apr 18, 2025 at 11:09:06PM -0400, gene heskett wrote:
    On 4/16/25 03:14, Erwan David wrote:
    On Wed, Apr 16, 2025 at 03:16:29AM CEST, Lee <[email protected]> said:
    On Mon, Apr 14, 2025 at 10:27 AM Dan Purgert wrote:
    On Apr 14, 2025, Marc SCHAEFER wrote:

    Which brings up the fact that if cups-browsed is present, it disables the factory drivers which run my 2 brother printers flawlessly, every feature listed on the boxes Just Works,  with the cups flavor of cups drivers which are grossly broken and have been for a decade or more. I lose tray choice, color is weak and afu on my color inkjet and my B&W laser loses duplex and doesn't properly respond to a formfeed.


    Hi Gene,

    This is probably off topic for the subject of the thread above but -

    You always claim that stuff is grossly broken: in this instance, CUPS
    is probably *not* broken. The problem is that the free drivers - which
    are essentially all that Debian can ship - are less functional than the proprietary drivers shipped by Brother. You have a Brother printer, you
    have the choice of which drivers to install. [And never forget, it was
    the problem of printing and non-free drivers that led Stallman to found
    the Free Software Foundation - printers are getting better but almost all contain non-free secret sauce].

    If you think that Debian isn't doing enough, ask Brother if they can
    free the propriatary drivers / help Debian developers work out *exactly*
    what's missing, or whatever, but maybe *do* something rather than always complaining that other people aren't doing enough? Even if you get
    nothing much useful back from Brother, at least they will be aware that
    there continues to be a user need for better free drivers and that Debian
    users are paying for and using their printers rather than those from another printer manufacturer so it's worth their continuing to support Linux.

    All the very best, as ever,

    Andy
    ([email protected])

    Cheers, Gene Heskett, CET.

    --
    "There are four boxes to be used in defense of liberty:
    soap, ballot, jury, and ammo. Please use in that order."
    -Ed Howdershelt (Author, 1940)
    If we desire respect for the law, we must first make the law respectable.
    - Louis D. Brandeis


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)