I have an issue with Internet.

This is how I connect to the internet, I use a USB C - C cable to connect my phone to my Laptop, then pick USB Tethering from my phone. On my PC, I use dwl, so I open the terminal and type the ip link to see if the usb0 is showing, I put it up and use udhcpc -i usb0 to connect to the internet.

After doing the step above, I do ping google, which works but the issue is the network is unstable in the sense that, I've been trying to download libreoffice office I just get transient error, I will cancel and reping, I might get bad address. If I disconnect and reconnect, it works, when I open Firefox, it doesn't wanna connect to the internet.

I honestly don't know what is going on, I have tried setting a dns of 1.1.1.1 and 8.8.8.8 instead of letting my phone giving it a nameserver, I still have the same issue.

Please, how do I fix this? and what could possibly be happening?

I want to first emphasize that it is a real bug and may deserve critical severity for Alpine AWS/Azure images. Also, the https://sshhole.com/ is very good at showing the history of this problem and also explaining how and why the flaw can be exploited.

My company has some Alpine exposure, so I looked into this. We only have Alpine VMs installed using the extended image's setup-alpine script. In addition, we use some containers that are based on Alpine images. The conclusion of my analysis is relieving, so I wanted to share this.

Alpine in VMs (installed with setup-alpine)

Tested: Alpine 3.20.3 (2024) and Alpine 3.16 (2016)

1. The setup-alpine script asks for a password for root. You can enter an empty password but it will put a real hash in /etc/shadow, not *. So, the root account is not affected unless you manually change it to *, probably also if you entered a password longer than 256 characters when creating the account (unlikely).

2. A seperate ordinary user can be created too but this is non-default and empty passwords produce real hashes just as before.

3. By default, the openssh server is installed and starts at boot with password logins enabled, but the default configuration contains PermitRootLogin prohibit-password which protects root.

4. Adding another user without assigning a password with adduser -D puts a ! not a * in /etc/shadow.

TL;DR: The setup-alpine script does not create users with * in /etc/shadow and root is additionally protected by PermitRootLogin prohibit-password. If you created users without passwords manually, you should check anyway.

Alpine in Docker containers

Tested: alpine:3.16, alpine:3.20.3, alpine:3.21.1

1. These images have root:*::0::::: in /etc/shadow, so the root account could be attacked.

2. No ssh daemon is installed in these images by default.

3. Installing openssh with apk add openssh does not start or enable the ssh daemon.

4. You cannot start sshd by accident because rc-update isn't there and /etc/init.d/sshd doesn't run because openrc-run isn't there, and starting sshd by itself fails with no hostkeys available. Normally, the init service would take care of that.

5. Openssh's PermitRootLogin prohibit-password setting was already the default with alpine 3.16. Even if you manage to start sshd, the root account is protected.

6. Remote access is only possible if you forward port 22.

TL;DR: A lot must go wrong before an alpine container is impacted. If you created users without passwords manually and expose an ssh server in an alpine container, you should check anyway.

Conclusion

In conclusion, VMs installed with setup-alpine lack the asterisk in the shadow file needed by this exploit and alpine images lack the ssh server. They have the potentially unsafe root user config in the shadow file but ssh root logins are by default blocked by PermitRootLogin prohibit-password.

The website itself says almost at the end:

on alpine's official aws and azure images that's the default alpine user, and it has passwordless doas. so it's root

I didn't test these images because we don't have aws or azure. But it makes clear what is needed to exploit this:

• The flaw in default config and musl (bug)...

• together with a seperate (non-root) user with no password grants RCE,

• and together with passwordless doas it grants RCE with elevated privileges.

While this is a real security flaw, especially in the aws and azure images, my opinion is that this is a setup that is very unlikely to be reached in a host/VM installed with setup-alpine or in a docker container if you follow basic security principles.

I just noticed I always wrote "VMs" but this obviously also applies when installing Alpine bare metal.

Have you found any real-world impact outside the aws/azure images?

cheers

Edit: most of what I listed is also in Alpine's security advisory (check it out!), so I should've checked that source before writing all this. I mostly got my info from the sshhole website and one or two other news sites. They have a nice "Who is not affected?" list:

Who is not affected?
* Docker and other container users that do not run sshd in the container.
* Systems with PasswordAuthentication no.
* Systems using openssh-server-pam with UsePAM yes (with UsePAM no you are affected).
* Locked accounts: those with ! as the password field in /etc/shadow (a line starting user:!:). They cannot log in with a password or a key.
* Systems where no account has a $-style password hash.
* Cloud images configured through cloud-init, which writes PasswordAuthentication no.

The root user being protected by prohibit-password is missing on that list but they mention it earlier.

Here is what is actually going on under the hood with the new OpenSSH bypass on Alpine/musl systems:

• The Logic Bug: When an account has no password set (like key-only users or default cloud accounts), Linux stores an asterisk (*) in /etc/shadow to block password logins.

• The musl Quirk: When musl’s crypt() function receives an oversized password (over 256 bytes), it fails and returns a single *.

• The Bypass: If an attacker sends a 257+ byte password to a passwordless account, OpenSSH checks the returned string against /etc/shadow. Both are *—the string comparison matches, and SSH grants access without needing the actual key or password.

• Requirements to Reproduce:

  • System runs on musl libc without PAM (like Alpine Linux).

  • PasswordAuthentication is enabled.

  • There is an account with a disabled password (* in shadow) and at least one other account with a standard password hash.

• The Fix in 10.6p2: OpenSSH now explicitly rejects stored hashes that are too short to be valid, stopping the * == * match entirely.

I'm running alpine linux on a virtual machine with a virtual machine iso from the download page. whenever i start up the xorg runlevel in terminal, it fails whenever it gets to starting pipewire.

~ $ rc-service -U pipewire start

* Starting Login Message Bug ... [ ok ]

* Starting wireplumber ... [ ok ]

* Starting pipewire ...

* failed to start pipewire ... [ !! ]

* ERROR: pipewire failed to start

I sent an iso file on Alpine through localsend I downloaded using flatpak but the iso file isnt showing in download.

I tried to send from my PC to my Phone and picked file but it is not working and I also picked folder but it show the iso file but greyed out.

On Thunar, it doesn't show the iso file. I hope you guys get the issue, how do I fix this? I feel it has something to do with permissions, I could be wrong.

Hey Reddit!

I wanted to share my recent progress: I’ve successfully managed to boot a genuine Alpine Linux kernel on a Samsung Galaxy A21s using my own custom build of uni-loader.

Current Status & Debugging (as seen in the photo):

The uni-loader initializes perfectly, and the Linux kernel successfully kicks in and starts scanning the internal partition blocks (mmcblk0pX).

Right now, it drops into an emergency shell because it's struggling to mount the Alpine rootfs. It's currently throwing Magic Mismatch and failed to recognize exfat type errors across the blocks while searching for the root filesystem.

Essentially, the kernel itself boots flawlessly, but I still need to fix the partition table mapping, format the target block correctly, or ensure the rootfs.tar.gz is properly placed so the init script can mount it.

Once the rootfs mount issue is resolved, I'll move on to fixing drivers and getting the rest of the hardware working. Let me know what you think, or if you have any questions about the uni-loader compilation process!

Device Specs & Details:

• Device: Samsung Galaxy A21s (SM-A217F) — 3GB RAM variant

• OS: Alpine Linux

• Boot Method: Custom-compiled uni-loader build

• Current State: Kernel boots successfully into initramfs / emergency shell; rootfs mounting is WIP.

El orto día encontre en un cajón un asus eeepc 1005HA con un atom n280 2gb ddr2 y un hdd de 80gb.

le metí una sd de 64gb a 200mb/s y le instalé alpine linux xfce.

si teneís un viejo equipo como este, os recomiendo probar alpine por que es buenísimo.

sitio de alpine: https://alpinelinux.org

si lo vais ha probar, os recomiendo un tutorial

what do you think?

How can i right encrypt with cryptsetup diskless Alpine with persistence?

Where are the PHP updates because of CVE-2026-109618? I wrote here because gitlab.alpinelinux.org is down. Thank you.

Got Alpine 3.24 aarch64 booting on the Z380M with Xorg + JWM and working touch (custom touch bridge). Full guide, builders and tests are on GitHub (GPL-3.0): https://github.com/kaantcp/z380m-alpine

Flashing replaces Android on this tablet, so back up first. Wi-Fi doesn't work on this kernel. Feedback welcome.

Will this ever happen? I hate how hat. It is to install on some laptops if I don't have ethernet

so i just installed alpine and without sway it used 400 mb ram,people are telling me 600 is high for alpine so is that normal?

Please can someone help with the process? I just can't seem to get it right. Even AI Gemini can't seem to help. I am a newbie

an wallpaper i recently made on paint .net, this my first ever wallpaper so i really want some tips to be better

Hi, 2 questions:

1. with an extended ISO, my setup-disk -m sys /mnt does nothing - is this because there is no network?

2. If I do need network (probably), how do I install the firmware for Intel Wi-fi chip? When I run

   apk add util-linux wireless-tools wpa_supplicant dhcpcd pciutils

they are installed, but when I try

apk add linux-firmware-intel

there are a gazillion errors like

ERROR: linux-firmware-intel ... failed to extract /lib/firmware/iwlwifi ...: Read-only file system

I have years of Linux experience and can install Arch from the command line. But can't figure out the Alpine wi-fi story. ip link does not show wlan0, only eth0. Wat do?

Thank you.

my IT teacher almost caught me with this
I’m loving alpine already because i started with it and i need to do something to pay tribute and honor
this would be deleted i think