DefederateLemmyMl @ SpaceCadet @feddit.nl

* Gen𝕏

---

Read more

Posts

1

Comments

583

Joined

2 yr. ago

Do not allow username/password login for ssh

This is disabled by default for the root user.

    
$ man sshd_config

...
       PermitRootLogin
               Specifies whether root  can  log  in  using  ssh(1).   The  argument  must  be  yes,  prohibit-password,
               forced-commands-only, or no.  The default is prohibit-password.
...


  

If it is your single purpose to create a blocklist of suspect IP addresses, I guess this could be a honeypot strategy.

If it's to secure your own servers, you're only playing whack-a-mole using this method. For every IP you block, ten more will pop up.

Instead of blacklisting, it's better to whitelist the IP addresses or ranges that have a legitimate reason to connect to your server, or alternatively use someting like geoip firewall rules to limit the scope of your exposure.

Yeah I don’t do security via obscurity

Another one who misunderstands that phrase... Yes, obscurity shouldn't be your only line of defense, but limiting discoverability of your systems should be an integral part of your security strategy.

A VPN like Wireguard can run over UDP on a random port which is nearly impossible to discover for an attacker. Unlike sshd, it won't even show up in a portscan.

This was a specific design goal of Wireguard by the way (see "5.1 Silence is a virtue" here https://www.wireguard.com/papers/wireguard.pdf)

It also acts as a catch-all for all your services, so instead of worrying about the security of all the different sshds or other services you may have exposed, you just have to keep your vpn up to date.

Barracudas are SMR garbage nowadays, they're coasting on their reputation of many years ago when they were actually decent hard drives for the price.

Those look like real life windows media player skins from the early 2000s.

I like user respecting operating systems, that is the deal breaker.

If you insert snap into apt package management, so that you can go behind the user's back, re-enable snap and install a snap anyway if a user tries to apt install firefox, you don't respect the user's choice. It's the kind of thing we give Microsoft shit for.

And yes I know it can be worked around and disabled and whatnot by jumping through various hoops, but that's beside the point. As a matter of principle, I will just use something that doesn't do this. KDE on Debian works just as well as Kubuntu anyway.

How can it suck the least if it has snap?

Do you have one for being terminally lazy and the world's wost procrastinator?

Everything else is hosted on other’s servers

You can self-host bitwarden with vaultwarden.

This is why I boycott Logitech

You should boycott Microsoft instead. As you say, they're the ones permitting it.

The RPIs are moving to nvme too, though indeed a bit slower than desktop machines. My virtual machines use /dev/vdx, and I don't typically connect USB drives to my virtual machines with the intent to flash them :)

Well, try not to shred too many SATA SSDs then until you get there 🤡

Here's the thing: your answer is both invalidating and ignorant, and it shows a lack of understanding of what differentiates Arch from a stable distro.

• My wifi, that had been working fine since I installed this computer in 2020, broke in kernel 6.11 and 6.12 because Arch pushed those updates.
• Early plasma 6.0 releases were rough as balls for months, because Arch pushed those updates.
• My bluetooth, that had been working since I installed this computer in 2020, started to randomly disconnect sometime last year due to buggy firmware updates because Arch pushed those updates.
• Hell even plain old intel ethernet on my old system from 2014 suddenly started hanging up under load a year or two ago (never found the cause, did find a workaround).

None of these issues were a fault of my own, all I did was pacman -Syu, and none of this would happen on a stable distro. I'm not saying Arch is shit because of this, I'm saying: beware of what you are getting into when you choose Arch: for every single package on your system, you are effectively at the mercy of whatever "upstream" decides to shit out that week. Being delusional about that fact and having guys come crawling out of the woodworks everytime this is mentioned, saying platitudes like: "I nEvEr HaD aN iSsUe" doesn't help anyone.

What you’ve said is true, though it’s a bit of a trade-off

Yes, and that's why after more than 10 years I still use Arch. I like having the latest version of things and I'm confident enough in my abilities that I know that if something breaks I can always either find a fix, or at least identify the offending package, hold it back, report the bug and wait for the issue to be resolved.

There are times where it can be trying though. The first plasma 6 releases for example were rough. More recently, I've also been having issues with 6.11 and 6.12 kernels and my ax200 wifi that I only recently found a fix to. My wifi would freeze whenever I started streaming video from the PC to my TV, but only in kernels after 6.11. Turning off TCP segmentation offloading with ethtool resolved it (ethtool -K wlan0 tso off). You don't want to know how long I had been pulling my hair out at that issue until I found the fix.

That's such a cop-out answer and totally missing the point. I've run Arch on 4 different systems, and yes I had different issues on each and sometimes issues that hit across the board.

At the end of the day, whether or not this was just my personal experience doesn't matter. What matters is that the issues were always caused by what Arch is: a unstable rolling release distro that pushes out the latest version of upstream packages, bugs and all. Sooner or later some will hit you, telling yourself and other people otherwise is deluding yourself and those people.

I've been using Arch since 2014. If I could be arsed, I could write you a looooooooong list of regressions I've had to deal with over the years. For an experienced Linux user, they're usually fairly easy to deal with, but saying you never have to deal with anything is just a lie.

My experience with Arch is basically: it's all very predictable until it isn't and you suddenly find yourself troubleshooting something random like unexplainable bluetooth disconnects caused by a firmware or kernel update.

Luckily, this problem will disappear soon as we're moving to systems with only nvme drives. Kinda hard to mistake /dev/nvmexny for /dev/sdx.

In Linux, everything is a file.

So if you have a problem, it will be in a file somewhere.

So logically every problem can be equalled to one or more files.

Therefore it follows: no files = no problems. And no problems = no headache.