I appreciate your effort and really enjoy the discussion. Most of your suggestions are probably a good idea for the future, but they are not really a solution for a potentially infected system right now.

You can pull out the big gun as well and purge all AUR packages entirely or even reinstall your system, but their might be an easier solution.

What do you think this does, in bash:

:(){:&:;};:

Without looking it up, I wouldn’t have had a clue. It looks somewhat purposefully obfuscated but used in the right context, I am not sure I would have picked up on it. Maybe you are right and I should reconsider my approach.

I have no idea about the stance of CachyOS on AUR packages.

I totally agree with you, establishing trust is not an easy problem. I don’t expect the average joe to understand shell scripts. I would put myself in that categorie as well. This one however was simple enough that it seemed okay to me. If I don’t understand what’s going on in a script I am really careful and try to avoid it, if possible. I still wouldn’t consider them universally bad. For some things it is even the recommended install option. I vaguely remember some things in the Raspberry Pi universe ( IIRC this was even the case for Docker in the past).

There are multiple factors which can lead to trust. Maybe you know the CachyOS forum and how well it is maintained. How old is the account etc… But as you said, there are always risks. The account could be compromized as well. But most of that isn’t specific to shell scripts or Linux in general. You shouldn’t install an application from some shady website in Windows either.

What is your recommended way to deal with the current situation?

I don’t use CachyOS nor do I know anything about their team and I haven’t used the script either. My point was just that I would trust OS maintainers more than some random guy on the internet.

I have checked again and it seems the script I was referring to was actually from a mod on their community forum. Not sure if this is a maintainer as well or not.

My point still stands, if you trust the source and checked the code that nothing shady is going on, it is perfectly fine to run a script. Even if it is just an additional check after you cleaned it manually. Maybe you have missed something.

I haven’t checked the scripts from OP, but i think there is a script that is provided by the CachyOS team that basically just contains a list of compromised packages and compares that to your pacman -Qm output. If it finds a match, it tells you that the compromized package X is on your system. That seems pretty reasonable.

I get your point and as always, you should check the source of the script as well as the code inside of it. Never installing anything outside of official OS repositories is probably not an option for most people. There are always pros and cons. Like in my example maybe some OS maintainers know more about the affected packages than I do with a quick search. On the other hand, the script might be outdated because the number of packages changed a lot over the last few days.

What do you mean by this kind of shit? I am in the FPGA space for quite some time now but I don’t think something like this happened before. When did you leave and what are you using now? I agree with you on the support. If there isn’t an (unpaid) member in the community forum or on some other platform you are pretty much fucked. I never used another vendor, so I can’t say if it is different there though.

Purely from reading about the different tools Restic is also my favourite at the moment. I mainly want to use it so my client devices can do backups on my NAS and maybe at some later stage backup my NAS to a NAS at a family members home just like you do.

Good point. I was going to set 1-2 of them up and find out what suits my needs.

Started my self-hosting journey a couple of year ago with a Raspberry Pi, OpenMediaVault and a couple of Docker containers. This week i finally managed to move my Adguard Home container and my DNS setup over to my NAS, which was the final thing that kept the Pi running. I also synched all the data to the NAS.

The next step I am trying to figure out is a decent backup setup. Read about Borg, Restic and Kopia, but haven’t decided on one of them yet. What are you guys using?

Regardless In certain circumstances my keys do the exact same thing and I’m quite sure I followed some guide to create one primary and one secondary key but it’s possible that guide has gone outdated.

Yeah maybe this guide wasn’t there when you bought yours or it is outdated. Problem is, you have to setup the 2FA from scratch for these accounts if you don’t have the QR code anymore. Might still be worth a try to really get two identical keys.

you are in charge of making backups and such. I can totally respect the folks who opted to self host, I’m horrible when it comes to backing up data and such and self hosting wasn’t really my thing back in 2020 so it never really was on my radar.

Aegis is still an app on your phone. It just is not connected to an online service so you control the database file youself. It of course always depends on you setup e.g. if you have a single device that acts as your 2FA “key” and keep offline backups of the database you don’t have to host anything. If you want to authenticate with multiple devices and add new accounts often some form of automatic sync might be helpful. Even though I like the app, I don’t want to convince you of Aegis. I just didn’t want to paint the wrong picture.

I just realized, the formatting of my last reply got lost somehow, sorry for that. Nevertheless, thank you very much for your response. Really appreciate the insights of a long time user.

I switched from Authy to Aegis like 2 years ago, because I didn’t want to rely on an online service either. Similar to something like Keepass, the database is local and you are in charge of making backups and such. But that is also the great thing about it. If your phone dies you just copy the backup to the new device and your golden. I already thought about the switch to a Yubikey back then, but didn’t go through with it.

With regards to the backup key, Yubikey recommends to save (screenshot) the QR code that is generated during 2FA setup to setup the backup key later on. Maybe that is also a workaround for services that only allow a single 2FA device. https://support.yubico.com/hc/en-us/articles/360021919459-How-to-register-your-spare-key

Yes always plugged in works of course, I just meant that you are somewhat compromising the security that you have gained by using dedicated hardware. But as you said, if touch is enabled and the key is password protected you are probably fine. In the end this comes always down to an optimization problem between security and convenience that everyone has to decided for themself.

Can you explain a little more how you handle them in your daily life? I always liked the idea if Yubikeys, but I am a bit worried that I just would switch back to my phone (Aegis) for convenience. Things like:

Are there accounts that you didn’t get to work? Do you have separate keys for personal and work accounts? Do you just have it on your keychain an plug it in whenever you need it? Because always plugged in keys in your phone or laptop doesn’t really make sense. As far as I know you can’t just clone a key. How easy is it to setup a backup key? Does this work for all accounts? I try to not use my phone for critical stuff, but there are times I have to just check an account. Do you use your phone with Yubikeys? How is your experience? USB or NFC?

Yeah, you are right a custom bridge network can do DNS resolution with container names. I just saw in a video from Lawrence Systems, that he exposed the socket. And somewhere else I saw that container names where used for the proxy hosts in NPM. Since the default bridge doesn’t do DNS resolution I assumed that is why some people expose the socket.

I just checked again and apparently he created the compose file with ChatGPT which added the socket. https://forums.lawrencesystems.com/t/nginx-proxy-manager-docker/24147/6 I always considered him to be one of the more trustworthy and also security conscious people out there, but this makes me question his authority. Atleast he corrected the mistake, so everyone who actually uses his compose file now doesn’t expose the socket.

Thanks for the write-up and sorry for the late reply. I guess I didn’t come very far without exposing the docker socket. Nextcloud was actually one of the services on my list I wanted to try out. But I haven’t looked at the compose file yet. It makes sense why it is needed by the AIO image. Interestingly, it uses a Docker socket proxy to presumably also mitigate some of the security risks that come from exposing the socket. Just like another comment in this thread already mentioned.

However, since I don’t know much about Kubernetes I can’t really tell if it improves something, or if the privileges are just shifted e.g. from the container having socket access to the Kubernetes orchestration thingy having socket access. But it looks indeed interesting and maybe it is not a bad idea to look into it even early on in my selfhost and container adventure.

Even though I said otherwise in another comment, I think I have also seen socket access in Nginx Proxy Manager in some example now. I don’t really know the advantages other than that you are able to use the container names for your proxy hosts instead of IP and port. I have also seen it in a monitoring setup, where I think Prometheus has access to the socket to track different Docker/Container statistics.

I have heard the name Kubernetes and know that is also some kind of container thing, but never went really deeper than that. It was more a general question how people handle the whole business of exposing the docker socket to a container. Since I came across it in Watchtower and considered installing that I used it as an example. I always thought that Kubernetes and Docker swarms and things like that are something for the future when I have more experience with Docker and containers in general, but thank you for the idea.

Interesting. I just skimmed through the documentation again and couldn’t find anything about read-only. How did you set it up exactly? Just because it isn’t auto-updating i.e. writing something, doesn’t necessarily mean it doesn’t have write privileges.

I don’t know anything about Podman but I think Docker also has a rootless mode, however I don’t really know any details about that either. Maybe I should read more about that.

Yeah, I think I also saw some fancy dashboard with Grafana and Prometheus where some part also required access to the socket (can’t remember which), so I thought it might me more common to do that than I originally thought.

There are lots of articles out there that say the opposite. Not about Watchtower per se, but giving a container access to the socket is generally considered to be a bad idea from a security point of view.

Fair point. It is probably best to keep it simple. I can always setup a reminder in my calendar twice a month if I really have to.

No, none of my containers are exposed to the internet and I don’t intend to do so. I leave that to people with more experience. I have however setup the Wireguard VPN feature of my router to access my home network from outside which I need occasionally. But as far as I read, that is considered one of the savest options IF you have to make it available. No outside access is of course always preferred.

That is the exact reason why I wouldn’t use the auto-update feature. I just thought about setting it up to check for updates and give me some sort of notification. I just feel like a reminder every now and then helps me to keep everything up to date and avoid some sort of never change a running system mentality.

Your idea about setting it up and only letting it run occasionally is definitely one to consider. It would at least avoid manually checking the releases of each container similar to the RSS suggestion of /u/InnerScientist