I would hardly call it your fuck up. You wanted to back up the data manually and were told not to - that's on your supervisor/boss/whoever called the shots. Not on you.

There is no reason to "pick a side". Situations like this aren't usually black and white.

You would need to specify the new port when using ssh (using the -p$PORT option). Just keep in mind that security through obscurity is not considered secure in itself. You could instead consider a service like fail2ban that automatically blocks connections from certain sources depending on your set parameters.

Do you believe that family should have all the same rights, protections and support your "traditional" family has?

As others already did I also would challenge your (purely) conservative tag. One of the most prominent "features" of current conservatives is to remove support and even legal standing of non-traditional families.

Which DE are you talking about? It sounds like KDE/Plasma but you didn't specify.

Es gibt von Nager IT faire Mäuse mit 2 bzw. 3 Tasten, vllt. ist das ja was: https://www.nager-it.de/maus/bestellung

Not OP, but they didn't flee to the country just for funsies but because there's war raging in their home country. They didn't choose to emigrate to a certain country because they always wanted to live there but because they feared for their lives.

It's a mixed bag. Personally I wouldn't use a non-standard port.

Consider that port numbers under 1024 are Privileged Ports. You would either have to make sure that no other privileged service is running on the port you want to use for SSH when using another privileged port or you need to make sure that no unprivileged program tries to use the same port as your SSH service when using a non-privileged. Overall it adds a bit of overhead and possible headaches for barely any gain.

Fail2ban should work with a different port without any further configuration but it might not.

Did you install any non-standard graphics drivers? If your system has an nVidia GPU bumblebee, nouveau and the closed-sourced driver all can cause this issue.

According to the debian wiki support is not fully guaranteed. Might just be that you ran into any of those issues:

Wayland support is still not finished yet though. Notably, there are issues with the compositor taking down other applications with it when it crashes, changing the global theme sometimes causes a session crash, "Activities" are unimplemented, there are various papercuts with drag-and-drop functionality, and session restoration only works with XWayland windows. A full and more regularly-updated list of Plasma Wayland issues can be found here: https://community.kde.org/Plasma/Wayland_Showstoppers

What @StarkZarn said is correct. Just one more thing: Did you reload/restart the sshd service after changing the configuration? If so you should be good.

Unfortunately X11 isn't without issues as well. In my case Wayland runs smoother and is less error prone than X11.

Can you confirm that it's only the taskbar that freezes? Do any other DE components (e.g. app launcher (shortcut meta + f2 by default)) work or do they freeze/not respond as well?

You could check various logs for errors:

• syslog (/var/log/syslog or dmesg)
• unit files of Plasma components (journalctl -xeu $UNITNAME; e.g. journalctl -xeu sddm.service)