• 0 Posts
  • 8 Comments
Joined 1 year ago
cake
Cake day: June 7th, 2025

help-circle
  • I think there is some confusion and potential for misinformation here. SSH in key-only mode (common configuration) protects you from this problem, because it never accepts or even attempts any passwords at all, regardless of length. SSH in password-allowed mode with at least one user who might be a key-only USER by merit of having a password hash of “*” (not a valid password hash) is a prerequisite for this. That is a very different and very common thing, as most systems come with at least one key-only user by default. But gaining access to that user with an incorrect, invalid password still requires having passwords enabled at all.

    To be clear: Password access enabled is a prerequisite, and by extension, password access disabled (key-only) prevents this.

    The website you linked clearly defines that all of these conditions must be true for you to be vulnerable, and as far as I can tell, it is exactly correct:

    is your sshd running on musl? (alpine, openwrt, buildroot, yocto)
    is it not using pam? alpine’s openssh-server doesn’t by default, or maybe you set UsePAM no
    are password logins still on? they are by default
    is there an account with just * as its password? key-only users, ldap users, root on alpine
    and some other account with a real password?

    then that * account takes any password between 257 and 1024 characters

    The * account which they suggest potentially being “key only” is the prerequisite you are talking about, but having SSH itself key-only (which is best practice anyway) prevents the attack entirely.


  • Open weight models cannot do this, they do not have any funding. If you demand this, you are just demanding that there will never be any open models, that proprietary AI models controlled by massive trillion dollar corporations will be the only models available, and frankly the cure is worse than the disease.

    It’s also impractical, like closing the gate after the horses have already gone. Open-weight, unethically trained models are already out there. They are not going away. You cannot put the genie back in the bottle. They will never earn any money, so they will never be able to compensate for the training that was done to create them, unless you consider the fact that they exist, and they are open to anybody, as at least some measure of compensation.

    It’s not enough compensation, but it is something. The training was certainly unethical, but so is an economic system that requires intellectual property to be transactional. Why fix one unethical thing while keeping and reinforcing another?

    The only sensible and reasonable way to resolve the issue in the long term is for significant government support and patronage of the arts and content creators (and ideally all people) to be established. People who do this for a living are providing valuable service to all of humanity and that deserves to be recognized not by transactional, metered capitalism that defines each piece of art or content in terms of its raw economic value (a system easily and frequently corrupted anyway if you look at the prevalence of theft, forgery, fraud and money-laundering in the high art world), but by guaranteeing a comfortable and dignified life that allows creative people to freely create the art or other works they love and feel passionate about without worrying that they’re going to starve to death or be forced into a dead-end job if they’re not economically successful.


  • I build a Linux system with multiple NICs. It’s heavyweight for a router, and probably not very efficient, but it does the job very well and I love it. I’m using foomuuri to manage the NFTables and NAT and it was very easy (although it’s a very obscure piece of software and the documentation and community isn’t excessively comprehensive, you might have better luck with something more common but it works nicely for me). It can pull in all the adblocking lists and all that fun stuff. I find it pretty intuitive to configure, at least compared to the horrors of most networking/routing configuration nonsense.

    For DHCP I tried using the ISC’s new “kea” in the hopes it would be modern and clean alternative to the venerable old isc-dhcp-server but it turned out to be a horrible mistake. They made some awful, insane, unjustifiable design decisions in that software. It gets confused about IP addresses already being claimed (by the exact same host/MAC) address because some arbitrary value changed in how it identifies itself, and then does absurd things with static leases, it just randomly decides to give it a dynamic lease instead, and then will fixate on that dynamic lease and never let it have the static lease back, I fought with it for months, it kept breaking my network for absolutely no reason and it was a nightmare.

    Back to trusty old isc-dhcp-server for me. And of course bind for DNS, I’m a bit old-school but it’s very comfortable.

    dnsmasq might be a lighter-weight and easier alternative you could consider, I think it does DHCP as well, convenient.

    And of course, being a full Linux server means you can put all kinds of other stuff on it too. Stuff that needs to be both publicly visible and privately visible on the LAN seems like an obvious fit, but in fact it’s probably the worst place to put those services, because you run into issues with NAT hairpinning and other nonsense. For services that are strictly intended for the private LAN/VPN, or services that are strictly public facing, it can handle those just fine by restricting them to a specific interface. But you should avoid stuff that needs to listen on both sides of the connection, it can be done, but it’s tricky and annoying and not ideal.

    If you need both internal and external access, port-forwarding from the outside through the NAT to another dedicated internal host is a much better solution if possible, it’s still a bit tricky (you may have to override the DNS for that domain internally to use the private IP instead of the public one) but it’s quite reliable and functional once you have it set up.

    None of this is really for the faint of heart, it’ll likely require a fair bit of trial and error and physical access to the machine to resolve issues. But it’s a fun project and I think the end result is worth it.


  • cecilkorik@piefed.catoSelfhosted@lemmy.world•*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    14
    arrow-down
    1
    ·
    1 month ago

    My biggest complaint is calling it “Pi” anything, there are already way too many things called “Pi”, some of which are for Raspberry Pi, some of which aren’t, and then there’s Pi itself (the number) it’s just an all-around confusing name and it sometimes makes related things incredibly difficult to search for and find.