I know rocky only implements what redhat does, but not everyone (in fact i think its quite rare except in large buisness environments where i worked before i retired), to use kerberos authentication.
therefore it seems to me it would be less trouble for people who are deploying from DVD if it was set to no by default.
buisnesses can always set it to yes in the kickstart script/build automation
Kerberos is far more common nowadays, even for smaller businesses. But that’s a different subject altogether.
That said, I cannot seem to replicate the above problem on my Rocky systems even when client-side has GSSAPIAuthentication enabled or disabled. The same with it enabled/disabled on the server-side as well. Be it Rocky → Rocky or I’ve even tried connecting to Rocky from Debian/Fedora → Rocky as well. So, yeah, a weird one.
I’m running Mint Cinnamon, DEB.
I confess I never checked Debian VMs because it just worked.
I ssh for the first time to setup the ssh-keygen for my user and that’s all, Ansible does the rest.
But again OPNSense is FreeBSD and it also just works.
I did applied that GSS.. on the server side among other options like NoDNS, you name it, but it seems to have been ignoring it altogether, that is why the ssh -o on the client side worked.
I first thought it was a RockyLinux issue since Google search returned more similar cases, the same happened with AlmaLinux so something was really wrong.
I had seen posts mentioning about that .ssh/config but again, this was never a thing so why should I need to have that file now.
Like you said, this was indeed a weird one.
For client-side you can edit /etc/ssh/ssh_config - and in this file you could have disabled GSSAPIAuth and it would then apply to all users on the system you are connecting from. Placing in ~/.ssh/config like you did is client-side settings in your home directory, so only applicable to your username. Handy if for example you are on a system and nobody gives you root access to be able to edit /etc/ssh/ssh_config.
I use the .ssh/config file all the time - be it for settings for SSH, or adding hosts and host configurations, eg: when a really old host still uses older ciphers, I can specify them to downgrade for one particular host. I’ve also used it for firewalls terminating SSH connections, and I added to it this bit of config:
Host *
ServerAliveInterval 300
ServerAliveCountMax 2
this would send keepalive and stop the firewall from terminating my session when I had left it open for a reason. The firewall would see lack of activity and terminate it. So I override it similar to what you did for this GSSAPIAuth issue.
I could have put it in /etc/ssh/ssh_config but since I back up my home directory means I keep the config I put without having to backup /etc/ssh/ssh_config as well.
The .ssh/config file in your home directory comes in handy for many many things. And like you there were years where I never even used it as well. So it’s not a case of why I have to use it now, more of another option you can use.
Of course, like I mentioned earlier, I could apply the config also on the server-side. But for me, I just edited one single file to keep my session alive, rather than having to configure 50+ servers for it. With Ansible, that wouldn’t be an issue either, since I could use Ansible to configure all 50+ in one go. That said, when I started using it, this was way before Ansible, so it made sense for me to create one single file and keep it for life, and my servers didn’t need to be changed 50 times manually.
Yep, that makes.
I use a jumper on our AWS cloud to access the VMs and the jumper requires A or ForwardAgent or the jump from it to the VMs does’t forward the authentication.
I gave it a try and no more adding bloody parameters on the call.
This is beautiful.
Host toolbox
ForwardAgent yes
Fun enough, the VM I am accessing from this jumper, drops your session if there is no activity. I am so borrowing that. I hardly ever have to access it but since I am already on this ssh mess, let me get used to this practice.
Thanks for the explanation