Should you have non-free-firmware in your sources.list? I don't think that would cause this problem but might cause problems with hardware support later.

I suspect the PREEMPT_DYNAMIC kernel. I have one system I use to run CUDA (on a Nvidia card) where I have to boot it with the default kernel, not the preempt one, to get CUDA to work.

If you have an option to boot the 6.1 default kernel could you try it to see if that's the problem?

It's not essential for CUDA either. Both the CUDA apps I use (gmp-ecm and msieve polynomial selection) work without it running.

I have got a system that runs CUDA on the GPU, but uses the onboard graphics to run the display. (It shares a monitor with 3 other systems via a KVM switch.) But for historical reasons it runs openSUSE 15.3 so I'm not sure how much I can help, beyond saying it is possible on some systems.

It has a GeForce GTX 970 with CUDA cuda-drivers-510 but a rather old motherboard (can't find the manual right now) in case that helps.

The message probably refers to /home/ziomario/.ssh/config on the system you are connecting from, not on the destination.

My advice to anyone with a similar problem would be to try ssh -v which would produce a lot more messages from ssh, which should tell you enough to solve the problem. If still stuck post *full* output here which should give us enough information to work out what the problem is.

I learnt that debuging ssh problems at work (although we had enough different OSes and ssh versions thatgetting them all to work properly took quite a while).

I would suspect something in /etc/profile or ~/.bash_profile, ~/.bash_login or  ~/.profile might be causing the wait. I'd start by putting echo "In .bash_profile" at the start of ~/.bash_profile (or ~/.bash_login or ~/.profile, whichever you have) and see if that comes out before or after the pause. If it's after the pause (or you don't have any of ~/.bash_profile, ~/.bash_login or  ~/.profile) then I would make a similar temporary change to /etc/profile to see if that's causing the pause. Then trace through the relevant script to find out what's causing the pause. Adding set -x to the script near the start could be helpful.

Keep notes of what you change so you can change it back when you have stopped investigating.

Try ssh -v devuan which should provide a lot of messages about the logon process. And look in /etc/ssh/sshd_config and /etc/ssh/sshd_config.d/ (grep -v '^#'  /etc/ssh/sshd_config to exclude comments should make it easier to see the relevant entries).

Post output from the commands here if you are still stuck.

Although I have had to resort to:
ps -ef | grep sshd
(assume that shows sshd is /usr/sbin/sshd.)
strings /usr/sbin/sshd | grep -i config

Just to be sure I was looking at the right config file. But that was working as a UNIX system admin when we had a wide range of OSes to look after.

I now seem to be back at "Can't upgrade from ascii because Nvidia have dropped support for running CUDA on my GPU". So I'll probably keep this system on ascii until the GPU dies. But at least I'm not short of disk space any more since the new disk is 1Tb and the old disk was 332Gb.

df -i show you the number of inodes in a filesystem. df --total show how many 1k blocks of disk space there are (in both cases you get total, used and available). See man df for details.

It's possible to run out of inodes but not space. This makes it impossible to add any new files to the filesystem. Which can be very confusing if you don't realise what's happened (I fell into this trap, though the disk was faulty and bought a new disk before realising I only needed to tidy up junk files).

Also you don't usually need to run df as root, it should work just as well as a non-root account.

The program that re-creates it probably deletes it before re-writing the latest contents into it. If you own .local/share/ then a program, running as you can delete files from it, even if you don't own them.

You might be able to stop this by making .local/share/ owned by root. But this would break anything else trying to create a file in .local/share/

I've not used doas (I learnt sudo before doas was available), but you will need to think hard about what you want to do. If you let people run an arbitrary command as root they could just run bash as root to get the same effect as doas -s.

With sudo it's possible to let people run a list of commands as root, but not a shell, as long as none of the commands you allow can spawn a shell. But it's easy to let a way to a root shell slip through.

Forcing people to jump through a few hoops to get to a root shell *might* have some value, but it's more likely to give you a false sense of security.

You should look at the cartoon in the April 2023 issue of Linux Magazine (Linux Pro Magazine in North America). It has an alternative meaning for the name.