[02:14] <wingarmac> Can someone help with this? https://paste.ubuntu.com/p/sGKdV8GNxd/
[02:15] <wingarmac> I've reinstalled both hosts, and it works a while, then again that message.
[02:18] <wingarmac> patdk-lap You were right about the TTY seats, I had to see how to set these manualy to understand its mechanism on lightdm.
[02:22] <sarnold> wingarmac: it looks a bit like you're 'sitting at' the ubcynt host, and you're trying to connect to the ubns host. you've created a private/public key pair on ubns, and then never use it. presumably one of those 'nano /etc/ssh/sshd_config' commands is disabling password authenitcation, but then you try to use password authentication to log in again
[02:23] <sarnold> wingarmac: the usual process is to make your ssh keypair on your LOCAL computer, and then copy the *public* portion of the keypair to the REMOTE ~/.ssh/authorized_keys  (use the ssh-copy-id command to make this less annoying)
[02:24] <sarnold> wingarmac: after you've got the public key installed in the remote host's ~/.ssh/authorized_keys file you can disable password authentication
[02:33] <wingarmac> sarnold, I just did solve it, by copy/paste the cat ~/.ssh/id_rsa.pub on ubns with echo ssh-rsa ****** wingarmac@ubcynt >> ~/.ssh/authorized_keys
[02:33] <sarnold> wingarmac: and did you make sure the permissions were correct? sshd is very picky about the permissions on the file and directory, too :)
[02:34] <wingarmac> ssh-copy-id command didn't work, as long as I'm refused.
[02:34] <sarnold> yeah, you'd have to fix that up first, hehe
[02:35] <sarnold> it's usually considered a bad idea to have the private key stored on multiple computers at once, though actual key management on multiple machines is a challenge.
[02:37] <wingarmac> I've 2 real hosts and 3 virtual hosts I try to maintain alone. It's sometimes overwhelming even if only for my own usage. any advice on hos to manage these keys in such context is welcome.
[02:43] <MTecknology> It sounds like the best place to start is some intro to linux documentation that gets you familiar with some of the basics. I think tldp is a decent place to start.
[02:45] <wingarmac> between access rights for files and ssh for me and/or for services I get lost quiet often. MTecknology You're probably right, but I do remind better when by practice. As I do not always understand how it is explained. 
[02:47] <wingarmac> Even so, I did find the solution to apply myself. And find therefor explanations that I could understand well on DigitalOcean and that worked out with this last issue.
[02:47] <MTecknology> There's a difference between learning and clicking what you're told; "learn best by practice" usually means something along the lines of someone else doing the learning for you.
[02:48] <wingarmac> I have an analogy to make you understand my insight: when you take on a find, you have no time to think, it has to be instinctive. That's how I do my job ;)
[02:49] <wingarmac> 'a fight'
[02:49] <MTecknology> "click wildly and hope something works"
[02:50] <wingarmac> nope, as you do not slash anywhere when you fight neither
[02:50]  * MTecknology re-recommends tldp and walks away
[02:50] <wingarmac> what is tldp ?
[02:56] <sarnold> the linux documentation project
[02:56] <sarnold> back in the 90s it was amazing; probably pieces have bitrotted over the years but it's still a pretty good starting point
[02:58] <wingarmac> The situation highlights the difference in learning styles. You prefer learning by doing ("kinesthetic learning"), while MTechnology might favor explanations first. This led to a communication gap. I'm sorry for that.
[03:00] <sarnold> there's certainly space for both :) we've just seen too many people blindly apply "chmod 777" to a permissions issue because they don't understand what they're working on, and I suspect that MTecknology is worried that you might be copying the private key around to all these machines, and thus making them basically one big transitive trust mess :)
[03:02] <MTecknology> "suspect that MTecknology is worried" .. partly that, but more generally, that's the attitude that leads to blindly copy/pasting/running commands that pipe some random script off the internet into sudo
[03:04] <wingarmac> These tests where applied on freshly installed ubuntu servers, with my files safeguarded. I can reinstall whenever I want and try it all over without loosing the most important. But I understand the concern. Also, this gives more work to people likely to assist others.
[03:06] <wingarmac> I was doing these tests exactly for learning how to make 2 hosts communicate seamlessly by ssh. The next step is service accounts and there relations with ssh, like for my ddns api with cloudflare. That will make some experience for sure.
[03:06] <sarnold> next up on the things to investigate list -- openssh certificates :) it feels like something you'd like
[03:06]  * MTecknology is currently writing documentation targeted toward lowest common denominator, which I can basically describe as "people who expect copy/pasting things from a website to magically work every time." It's frustrating because these are the users that have no idea what they're actually doing, or why, or how to handle an issue, or even how to identify if they ran into an issue.
[03:11] <wingarmac> We have 2 kind of user: The one that uses the systems, and the one that configures the systems. We can't expect from users to become all well advices of the correct maintenance practices. that's why automated solutions are developed. So I would consider the type of user it is, and adapt consequently. some do say Linux isn't made for such users, but I do not totaly agree with that. Some distros like Mint are made for 
[03:11] <wingarmac> these.
[03:11] <MTecknology> You can make whatever excuse you want, but the real-world outcome remains the same.
[03:12] <wingarmac> Not an excuse, exclusivity.
[03:12] <wingarmac> and adaptability.
[03:13] <wingarmac> corrected myself: inclusive and adaptability, so am I
[03:14] <wingarmac> We need experts, and we also need experiences. The best experiences for learning are in failures.
[03:15] <MTecknology> Your own questions and issues are evidence against your claims. I recommended tldp because you very clearly need to learn about some of the basics ... based on the confusion you presented here.  Whatever you do with that recommendation is up to you. If you want to take your troubles there to learn about those troubles, then go for it. If you want to keep shoving your question into chatgpt and hope to learn something from what it 
[03:15] <MTecknology> returns, then ... whatever, just don't be surprised when the thing you're working on breaks and nobody else can help you due to not having any idea what you did in the first place.
[03:16] <MTecknology> I'm gonna drop you into my /ignore list because it seems like you're more excited about arguing than learning and I don't really care.
[03:16] <wingarmac> i do as we do in martial arts, repeating until I do it right ;)
[03:17] <wingarmac> you di read how many times, before you did reccord the data?
[03:19] <wingarmac> I know I can handle my way, but anyway thanks for your willing to assist.
[12:10] <PeGaSuS> so, I'm still facing the `/usr/bin/ld: error: /lib/x86_64-linux-gnu/libkeyutils.so.1: file too short` issue. if I delete the file and create the symlinkl manually all works fine until the next upgrade
[12:10] <PeGaSuS> this starts to annoy me
[22:58] <Phibs> anyone gotten multitrap to work with U24.04  ? Seems that a few packages clobber the /bin symlink and make it a directory :(
[22:58] <Phibs> multistrap *
[23:08] <Phibs> .w 72