> some default container images apparently have a default alpine user with that hash
Do you have an example? Looking at Alpine's advisory, I can only see that their cloud images (i.e. what you use to run a VM, not a container) have a default alpine user, no container images. And even with those, cloud images with cloud-init are unaffected with default config due to `PasswordAuthentication no` being inserted by cloud-init into sshd_config. So that leaves... Cloud images that use Tiny Cloud for provisioning. That's an instance bootstrapper authored by Alpine from the looks of it so I'm not sure how many people would prefer that over cloud-init (which a lot of VM/bare metal management software may already make easy to use) or just a non-cloud image.
Alpine is mostly used in containers, where you don't run sshd anyway. It apparently doesn't use PAM by default though.
OpenWRT also doesn't use PAM by default apparently, and there is a risk of people using password login, which you should never do past initial setup.
But outside specific niches, musl is rare, with good reason. Performance is a joke compared to glibc, especially the allocator. The only reason to choose musl in my opinion is for memory constrained devices (OpenWRT etc) or for building static binaries where performance doesn't matter but portability does. I consider the "small container" use case questionable: performance will suffer, and you could share large base layers instead which would amortize the cost over many different images.
Yeah, OpenWRT doesn't use openssh by default - it uses dropbear. You can install openssh, if you want more features and there seem to be 2 packages - one with PAM support (openssh-server-pam) and one without it (openssh-server). PAM-less one is the one without the suffix so perhaps it's more likely you'd install that one out of the two, but only if you were trying to switch to using openssh in the first place.
Nowadays, when banks call you here, they allow you to verify the bank is actually calling you with the mobile app - you can see their name and number they're calling you from in the app. Also, you can often verify you're you with the app too, same as any other app authorization, so you don't have to share any details over the phone. I feel like this is a pretty good improvement.
That does seem better than blind trust but that app infrastructure could get compromised. I would still be wary in any situation where I did not originate the call with the bank.
Ye, I only get called by banks when my transaction gets classified as potentially fraudulent (which pretty much just means that it is for a bigger amount of money) or some other even more rare situations like finishing a loan application. Still, I'd rather be double sure that it is the bank that's calling me because I don't want to assume solely based on the convenient timing.
If the app infrastructure is compromised, the bank is liable so it feels like less of a problem. If the app does offer authorizing through the app, I shouldn't be asked any personal details that my bank already knows so I (hopefully) would still be wary, if put in such a situation though. Obviously hard to know what I'd actually do unless it actually happens to me.
Do you have an example? Looking at Alpine's advisory, I can only see that their cloud images (i.e. what you use to run a VM, not a container) have a default alpine user, no container images. And even with those, cloud images with cloud-init are unaffected with default config due to `PasswordAuthentication no` being inserted by cloud-init into sshd_config. So that leaves... Cloud images that use Tiny Cloud for provisioning. That's an instance bootstrapper authored by Alpine from the looks of it so I'm not sure how many people would prefer that over cloud-init (which a lot of VM/bare metal management software may already make easy to use) or just a non-cloud image.
reply